From Newsgroup: alt.privacy

Jacques wrote:

YAMN WEB INTERFACE.
https://yamnweb.virebent.art/

Can I use it to send messages to a email address?
I tried but I did not receive the message.

Yes, Yamnweb can send messages to regular email addresses.

Delivery is asynchronous: the message first travels through Nym and is then placed in
the YAMN delivery spool, so submission does not mean immediate inbox delivery.

Delays of several minutes/hours are possible.
Please also check your Spam/Junk folder.

Let us know ;)

The Virebent Family

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Mr Anderson wrote:

Never ever use any of these clear text remailer programs for sensitive posts.

Have you heard of "client side scanning?"

https://epublications.substack.com/p/client-side-scanning-the-end-of-privacy

For sensitive posts you should really use an offline computer to pgp encrypt your messages and then transfer the encrypted message to your online computer via a usb stick or such like. Then send your message (chained) through Cypherpunk remailers.

Even Omninix is not safe as you have to use windows and windows does client side scanning and it it also takes snapshots of everything you do!!!

This is a valid endpoint-security warning, but it does not accurately describe Yamnweb’s threat model. Yamnweb explicitly states that plaintext reaches the web server before the local Go encoder builds the layered YAMN envelope. Nym then transports only that opaque envelope to the Entry, followed by the YAMN Entry, Middle and Exit chain.

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Gabx


--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?
--
https://oc2mx.net
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Ch1ffr3punk wrote:

Anonymous wrote:

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?

It would not fully address the endpoint-compromise scenario i described.
YAMN encoding is currently performed server-side, so plaintext necessarily reaches the Yamnweb host before encoding.

MFV could certainly strengthen Yamnweb by providing verifiable integrity and timestamped proofs for the published frontend,but not as a complete replacement for an offline or locally verified client in high-risk situations.

A stronger option would be to encrypt the message with AEC on an air-gapped computer, then import the encrypted QR payload into Yamnweb.

Yamnweb could support local browser-side QR decoding, without uploading the QR image, and transport only the AEC ciphertext inside the YAMN envelope.

Gabx




--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:> Ch1ffr3punk wrote:

Anonymous wrote:

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?

It would not fully address the endpoint-compromise scenario i described.
YAMN encoding is currently performed server-side, so plaintext necessarily reaches the Yamnweb host before encoding.

MFV could certainly strengthen Yamnweb by providing verifiable integrity and timestamped proofs for the published frontend,but not as a complete replacement for an offline or locally verified client in high-risk situations.

A stronger option would be to encrypt the message with AEC on an air-gapped computer, then import the encrypted QR payload into Yamnweb.

Yamnweb could support local browser-side QR decoding, without uploading the QR image, and transport only the AEC ciphertext inside the YAMN envelope.

To clarify, AEC would be useful not only if the Yamnweb server were compromised, but whenever the online computer, browser or web service is not fully trusted.

It protects the plaintext by ensuring that the online environment receives only ciphertext, although it cannot protect a compromised offline computer, the recipient’s endpoint, or transmission metadata.

Virebent

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

Anonymous wrote:> Ch1ffr3punk wrote:

Anonymous wrote:

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?

It would not fully address the endpoint-compromise scenario i described. YAMN encoding is currently performed server-side, so plaintext necessarily reaches the Yamnweb host before encoding.

MFV could certainly strengthen Yamnweb by providing verifiable integrity and timestamped proofs for the published frontend,but not as a complete replacement for an offline or locally verified client in high-risk situations.

A stronger option would be to encrypt the message with AEC on an air-gapped computer, then import the encrypted QR payload into Yamnweb.

Yamnweb could support local browser-side QR decoding, without uploading the QR image, and transport only the AEC ciphertext inside the YAMN envelope.

To clarify, AEC would be useful not only if the Yamnweb server were compromised, but whenever the online computer, browser or web service is not fully trusted.

It protects the plaintext by ensuring that the online environment receives only ciphertext, although it cannot protect a compromised offline computer, the recipient’s endpoint, or transmission metadata.

Virebent

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.
--
https://oc2mx.net
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Ch1ffr3Prank wrote:

Anonymous wrote:

Anonymous wrote:> Ch1ffr3punk wrote:

Anonymous wrote:

If the user’s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?

It would not fully address the endpoint-compromise scenario i described. >> > YAMN encoding is currently performed server-side, so plaintext necessarily reaches the Yamnweb host before encoding.

MFV could certainly strengthen Yamnweb by providing verifiable integrity and timestamped proofs for the published frontend,but not as a complete replacement for an offline or locally verified client in high-risk situations.

A stronger option would be to encrypt the message with AEC on an air-gapped computer, then import the encrypted QR payload into Yamnweb.

Yamnweb could support local browser-side QR decoding, without uploading the QR image, and transport only the AEC ciphertext inside the YAMN envelope.

To clarify, AEC would be useful not only if the Yamnweb server were compromised, but whenever the online computer, browser or web service is not fully trusted.

It protects the plaintext by ensuring that the online environment receives only ciphertext, although it cannot protect a compromised offline computer, the recipient’s endpoint, or transmission metadata.

Virebent

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

As the yamn network is the weakest par of the chain.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Nomen Nescio wrote:

Ch1ffr3Prank wrote:

Anonymous wrote:

Anonymous wrote:> Ch1ffr3punk wrote:

Anonymous wrote:

If the user???s operating system, browser or the Yamnweb host is compromised before encryption, no remailer network can repair that loss of confidentiality. For high-risk communication, composing and encrypting on a separate trusted system is therefore appropriate.

Can't mfv secure Yamnweb?

It would not fully address the endpoint-compromise scenario i described.
YAMN encoding is currently performed server-side, so plaintext necessarily reaches the Yamnweb host before encoding.

MFV could certainly strengthen Yamnweb by providing verifiable integrity and timestamped proofs for the published frontend,but not as a complete replacement for an offline or locally verified client in high-risk situations.

A stronger option would be to encrypt the message with AEC on an air-gapped computer, then import the encrypted QR payload into Yamnweb.

Yamnweb could support local browser-side QR decoding, without uploading the QR image, and transport only the AEC ciphertext inside the YAMN envelope.

To clarify, AEC would be useful not only if the Yamnweb server were compromised, but whenever the online computer, browser or web service is not fully trusted.

It protects the plaintext by ensuring that the online environment receives only ciphertext, although it cannot protect a compromised offline computer, the recipient???s endpoint, or transmission metadata.

Virebent

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

Oufiles are as old as Mixmaster and are intended for that, in case
devices are compromised.
--
https://oc2mx.net
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas sucks wrote:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

As the yamn network is the weakest par of the chain.

Dead wrong.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

Claas sucks wrote:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all adds up for the worst.

As the yamn network is the weakest par of the chain.

Dead wrong.

Sure, it is, but you have never been a remop to see this and
how exaclty all this works...
--
https://oc2mx.net
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

An ordinary Usenet post is intended to become public, so plaintext
visibility at Yamnweb or at the YAMN Exit is not a lasting content-confidentiality issue, although source metadata and
pre-publication exposure still matter.
Encrypted posts in alt.anonymous.messages are a differen case.

Private email intended to be end-to-end encrypted for the final
recipient must be encrypted before it is submitted through the Yamnweb interface.

When only ciphertext is transferred, neither Yamnweb nor the YAMN Exit
can access the plaintext.

Submitting a complete YAMN outfile provides additional protection
because Yamnweb cannot see the final recipient, subject, message
content, or the remaining remailer route beyond the first Entry.

The concerns raised do not apply equally to every use case.
Ordinary Usenet posts are intended for public distribution, while
end-to-end encryption of private email for a specific recipient remains
the sender’s responsibility.

Yamnweb can improve this workflow by accepting AEC ciphertext or YAMN
outfiles,
in the next future.

Yamnweb does not claim to replace recipient-level encryption.

Gabx
---
we live in hell
but we live well

--- Digital Signature --- aCKnuLwaEwq3UNKV0jyqpkL9SPs14X0z1x2kjPVH2CA5NxP/c485ZGo6Qd4eY3QicoLKQWR6Sts7kFJh6QDwBg==

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas wrote:

Anonymous wrote:

Claas sucks wrote:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid >> > > as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

As the yamn network is the weakest par of the chain.

Dead wrong.

Sure, it is, but you have never been a remop to see this and
how exaclty all this works...

How will you know?

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

Claas wrote:

Anonymous wrote:

Claas sucks wrote:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all adds up for the worst.

As the yamn network is the weakest par of the chain.

Dead wrong.

Sure, it is, but you have never been a remop to see this and
how exaclty all this works...

How will you know?

Because I was a remop as well.

The weakest part in classic TypeII smtp(s) remailing are the
remops.

a) Do you exactly know what kind of person a remop is and if
he logs and has additional shell scripts running, or is working,
via a gag-order, together with authorities?

b) Do remops have a website with a warrant canary?

c) The pools of TypeII remailers are open and not encrypted,
like the Onion Courier Mixnet does *in RAM*.

d) TypeII smtp(s) clearnet remailers have timestamps in the
files of the open pool, third parties can access, without
the knowledge of a remop.

e) Only the Tor Network can protect, as good as possible,
the users of TypeII smtp(s) remailers.

and so on ...
--
https://oc2mx.net
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 23 Aug 2026, yamn sucks <nobody@domain.invalid> posted some news:1787554577.66EB209DA4057095@domain.invalid:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward them
through a garbage web interface to the Yamn network? That's as stupid
as can be. Though it comes as no surprise, because once again it all
adds up for the worst.

As the yamn network is the weakest par of the chain.

Sure it is, Danny.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 24 Aug 2026, Anonymous <nobody@remailer.paranoici.org> posted some news:45a6cee657fafb09cebf3778c650ac58@remailer.paranoici.org:

Claas wrote:

Anonymous wrote:

Claas sucks wrote:

Nomen Nescio wrote:

With a Yamn tool from you. Create remailer packets. To forward
them through a garbage web interface to the Yamn network?
That's as stupid as can be. Though it comes as no surprise,
because once again it all adds up for the worst.

As the yamn network is the weakest par of the chain.

Dead wrong.

Sure, it is, but you have never been a remop to see this and
how exaclty all this works...

How will you know?

The knock on the door at 3 AM. That's why you hack your neighbor's
wireless network and use his so they knock there.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

The knock on the door at 3 AM. That's why you hack your neighbor's
wireless network and use his so they knock there.

Not so, when cops are called in that's one of the first things they
look for!

You would not make hacker grade school!

<https://www.youtube.com/watch?v=mxBcTV7knck>

<https://www.fortinet.com/resources/cyberglossary/wardriving>

<https://us.norton.com/blog/hacking/wardriving-what-it-is-and-how-to-help-protect-your-network>

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Ch1ffr3punk wrote:

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

This is exatly what i have done.
For encrypted body emails users, "yamn tools" give the possibility to
encrypt the whole email together with its metadata, for yamn entry point.

Now, Yamnweb under the submit botton shows the yamn offline tools menu.
It has links to "yamn offline tools" download and to a "yamn offline
tools" guide.

There is the data input where users can paste their encrypted text body,
and a menu where choose remailer entry node.

https://yamnweb.virebent.art
--
https://contact.virebent.art
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/5/2026 2:18 AM, Gab virebent wrote:

Ch1ffr3punk wrote:

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

This is exatly what i have done.
For encrypted body emails users, "yamn tools" give the possibility to encrypt the whole email together with its metadata, for yamn entry point.

Now, Yamnweb under the submit botton shows the yamn offline tools menu.
It has links to "yamn offline tools" download and to a "yamn offline
tools" guide.

There is the data input where users can paste their encrypted text body,
and a menu where choose remailer entry node.

https://yamnweb.virebent.art

Where is this encrypting? In here?

https://yamnweb.virebent.art/pow-worker.js

Its on a server somewhere? How is this client side encryption?
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/5/2026 2:05 PM, Chris M. Thomasson wrote:

On 9/5/2026 2:18 AM, Gab virebent wrote:

Ch1ffr3punk wrote:

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

This is exatly what i have done.
For encrypted body emails users, "yamn tools" give the possibility to
encrypt the whole email together with its metadata, for yamn entry point.

Now, Yamnweb under the submit botton shows the yamn offline tools menu.
It has links to "yamn offline tools" download and to a "yamn offline
tools" guide.

There is the data input where users can paste their encrypted text body,
and a menu where choose remailer entry node.

https://yamnweb.virebent.art

Where is this encrypting? In here?

https://yamnweb.virebent.art/pow-worker.js

Its on a server somewhere? How is this client side encryption?

Are you trying to validate the page contexts, all data loaded into the
client against a hash in the server?
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/5/2026 2:18 AM, Gab virebent wrote:

Ch1ffr3punk wrote:

Why not keep Yamnweb very simple...?! Only allow as input field
YAMN outfiles and users can then later, with one YAMN tool from
me, include an AEC QR-Code in the YAMN outfile payload. That is
most secure and also a MIME compliant attachment later, to been
viewed in the receiver's email inbox.

This is exatly what i have done.
For encrypted body emails users, "yamn tools" give the possibility to encrypt the whole email together with its metadata, for yamn entry point.

Now, Yamnweb under the submit botton shows the yamn offline tools menu.
It has links to "yamn offline tools" download and to a "yamn offline
tools" guide.

There is the data input where users can paste their encrypted text body,
and a menu where choose remailer entry node.

https://yamnweb.virebent.art

what is this:

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

a public hash?
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Chris M. Thomasson wrote:

what is this:

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

a public hash?

Hi dude,

pow-worker.js does not encrypt messages.
It calculates a client-side proof of work used to limit abuse.

To avoid automation spam bots i have set a "proof of work" to make
automated postings a lot harder.

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

The hexadecimal value was not being used to validate the page.

It was simply the SHA-256 checksum of an older YAMN Offline Tools
archive, published so users could verify their download.

The current archive is:

ch1ffr3punk-yamn-offline-tools-source-20260905.tar.gz

Current SHA-256:

87a5e847643133424e4ff22694f16c2cede0e887d359d5de8b3bfbf18456b6e7

A SHA-256 checksum provides a practically unique identifier for a
digital file and allows users to verify its integrity.
If the checksum calculated after downloading the file differs from the published value, the file has been altered, corrupted, or is not the
expected file.

If you have any other question,
don't hesitate.

Best regards

Gabx
--
https://contact.virebent.art
gemini://contact.virebent.art
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/5/2026 3:14 PM, Gab virebent wrote:

Chris M. Thomasson wrote:

what is this:

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

a public hash?

Hi dude,

pow-worker.js does not encrypt messages.
It calculates a client-side proof of work used to limit abuse.

To avoid automation spam bots i have set a "proof of work" to make
automated postings a lot harder.

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

The hexadecimal value was not being used to validate the page.

It was simply the SHA-256 checksum of an older YAMN Offline Tools
archive, published so users could verify their download.

The current archive is:

ch1ffr3punk-yamn-offline-tools-source-20260905.tar.gz

Current SHA-256:

87a5e847643133424e4ff22694f16c2cede0e887d359d5de8b3bfbf18456b6e7

A SHA-256 checksum provides a practically unique identifier for a
digital file and allows users to verify its integrity.
If the checksum calculated after downloading the file differs from the published value, the file has been altered, corrupted, or is not the expected file.

If you have any other question,
don't hesitate.

Yeah. I was looking for an algo wrt client side encryption. The main encryption is on your server(s). Sorry for the misunderstanding.

How does the user message reach the server without being encrypted first?


[...]
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Chris M. Thomasson wrote:

How does the user message reach the server without being encrypted first?

For encrypted emails i have set Yamn Offline Tools.

Yamnweb interface, in yamn offline message part, by clicking on the
arrow, it takes you to Yamn Offline Tools web interface.

You can download the tar.gz package which has also a install.sh script
to easy installation and configuration of both yP and yM tools with
golang. It will care of version checking and golang install, only for
linux platform.

There is a data input where paste your encrypted message for a yamn
remailer entry.

Soon a Win-dows version.

Download here: https://yamn.virebent.art/downloads/ch1ffr3punk-yamn-offline-tools-source-20260905.tar.gz

SHA-256: 87a5e847643133424e4ff22694f16c2cede0e887d359d5de8b3bfbf18456b6e7

Here instructions:

https://yamn.virebent.art/guide-yamn-offline-tools.html#packet

Packets travel in tlsv1.3, onion or both to the web interface and than
through nym and yamn network.

Best regards
Gabx
--
https://contact.virebent.art
gemini://contact.virebent.art
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/6/2026 12:49 PM, Gab virebent wrote:

Chris M. Thomasson wrote:

How does the user message reach the server without being encrypted first?

For encrypted emails i have set Yamn Offline Tools.

Yamnweb interface, in yamn offline message part, by clicking on the
arrow, it takes you to Yamn Offline Tools web interface.

You can download the tar.gz package which has also a install.sh script
to easy installation and configuration of both yP and yM tools with
golang. It will care of version checking and golang install, only for
linux platform.

There is a data input where paste your encrypted message for a yamn
remailer entry.

Soon a Win-dows version.

Download here: https://yamn.virebent.art/downloads/ch1ffr3punk-yamn-offline-tools- source-20260905.tar.gz

SHA-256: 87a5e847643133424e4ff22694f16c2cede0e887d359d5de8b3bfbf18456b6e7

Here instructions:

https://yamn.virebent.art/guide-yamn-offline-tools.html#packet

Packets travel in tlsv1.3, onion or both to the web interface and than through nym and yamn network.

I see. To clarify: So, download, you site "auto" verifys, encrypt, post encrypted payload?

My experiment has the encryption on the client side. It is as it is.
From my server. However, the user can download the site, and use a hash
to verify it. Like you are doing with your offline downloads?

https://fractallife247.com/test/hmac_cipher/drmoron/?ct_hmac_cipher=ded1f0271579f9dfcb399eac22bc3de8faed8989aa4f8a6208c5e91a385950aa0a50b1e8f3ce549bf67b48aed0459cc3a14da1c277f9069e6abbaff339125b794f248e313dc8bd81ebadf7ce7afa9858fef4920be68688bf3c0aff686001971a5801ac1a4dcea327c013b381c90d2a7cc7
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 06 Sep 2026, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>

On 9/5/2026 3:14 PM, Gab virebent wrote:

Chris M. Thomasson wrote:

what is this:

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

a public hash?

Hi dude,

pow-worker.js does not encrypt messages.
It calculates a client-side proof of work used to limit abuse.

To avoid automation spam bots i have set a "proof of work" to make
automated postings a lot harder.

9a6ecac542afb79a109867376ab7ec8b620e7c5517017be9aa0aa3d1f22445ea

The hexadecimal value was not being used to validate the page.

It was simply the SHA-256 checksum of an older YAMN Offline Tools
archive, published so users could verify their download.

The current archive is:

ch1ffr3punk-yamn-offline-tools-source-20260905.tar.gz

Current SHA-256:

87a5e847643133424e4ff22694f16c2cede0e887d359d5de8b3bfbf18456b6e7

A SHA-256 checksum provides a practically unique identifier for a
digital file and allows users to verify its integrity.
If the checksum calculated after downloading the file differs from
the published value, the file has been altered, corrupted, or is not
the expected file.

If you have any other question,
don't hesitate.

Yeah. I was looking for an algo wrt client side encryption. The main encryption is on your server(s). Sorry for the misunderstanding.

How does the user message reach the server without being encrypted
first?

[...]

Put the lines in the envelope, then you feel better.
Put the lines in the envelope, seal it all up.
Put the lines in the envelope, send it all out.
Put the lines in the envelope, and pray it gets there.
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Chris M. Thomasson wrote:

I see. To clarify: So, download, you site "auto" verifys, encrypt, post encrypted payload?

My experiment has the encryption on the client side. It is as it is.
From my server. However, the user can download the site, and use a hash
to verify it. Like you are doing with your offline downloads?

https://fractallife247.com/test/hmac_cipher/drmoron/?ct_hmac_cipher=ded1f0271579f9dfcb399eac22bc3de8faed8989aa4f8a6208c5e91a385950aa0a50b1e8f3ce549bf67b48aed0459cc3a14da1c277f9069e6abbaff339125b794f248e313dc8bd81ebadf7ce7afa9858fef4920be68688bf3c0aff686001971a5801ac1a4dcea327c013b381c90d2a7cc7

I followed your link. It contains 113 bytes of hexadecimal ciphertext
and decrypts locally in the browser, using the visible default password Password, SHA-512 and a 73-byte random prefix.

YAMN Offline Tools works locally too, but builds a standard YAMN
encrypted outfile.

The normal Yamnweb form is different: its fields reach the server over encrypted transport before server-side YAMN encoding.

Best regards
Gabx
--
https://contact.virebent.art
gemini://contact.virebent.art
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/6/2026 3:39 PM, Gab virebent wrote:

Chris M. Thomasson wrote:

I see. To clarify: So, download, you site "auto" verifys, encrypt,
post encrypted payload?

My experiment has the encryption on the client side. It is as it is.
 From my server. However, the user can download the site, and use a
hash to verify it. Like you are doing with your offline downloads?

https://fractallife247.com/test/hmac_cipher/drmoron/?
ct_hmac_cipher=ded1f0271579f9dfcb399eac22bc3de8faed8989aa4f8a6208c5e91a385950aa0a50b1e8f3ce549bf67b48aed0459cc3a14da1c277f9069e6abbaff339125b794f248e313dc8bd81ebadf7ce7afa9858fef4920be68688bf3c0aff686001971a5801ac1a4dcea327c013b381c90d2a7cc7

I followed your link. It contains 113 bytes of hexadecimal ciphertext
and decrypts locally in the browser, using the visible default password Password, SHA-512 and a 73-byte random prefix.

Thanks! I am glad it worked for you. :^) I have not tested it on a shit
load of browsers yet. ;^o

YAMN Offline Tools works locally too, but builds a standard YAMN
encrypted outfile.

The normal Yamnweb form is different: its fields reach the server over encrypted transport before server-side YAMN encoding.

Okay. I am not familiar with Yamnweb. But, actually, you made me think
of storing a hash of my site (all the bytes comprising the
javascript/html). So, when a user downloads my site to run offline, they
can compare the hash of all of it to the one on the server?
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On 9/6/2026 3:07 PM, Fritz Wuehler wrote:

On 06 Sep 2026, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>

[...]

How does the user message reach the server without being encrypted
first?


[...]

Put the lines in the envelope, then you feel better.
Put the lines in the envelope, seal it all up.
Put the lines in the envelope, send it all out.
Put the lines in the envelope, and pray it gets there.

rofl! :^)

--- Synchronet 3.21e-Win32 NewsLink 1.2