The maintainer has released a Debian package repo for ease of install.

Veilid: A secure peer-to-peer network for apps that flips off the
surveillance economy:
https://www.theregister.com/2023/08/12/veilid_privacy_data/

[copypasta]

site: https://veilid.com/

Veilid (pronounced Vay-Lid, from 'Valid and Veiled Identification')

Veilid allows anyone to build a distributed, private app. Veilid gives
users the privacy to opt out of data collection and online tracking.
Veilid is being built with user experience, privacy, and safety as our
top priorities. It is open source and available to everyone to use and
build upon.

Veilid goes above and beyond existing privacy technologies and has the
potential to completely change the way people use the Internet. Veilid
has no profit motive, which puts us in a unique position to promote
ideals without the compromise of capitalism.

[/copypasta]

Instructions to install a VeilID node

https://gitlab.com/veilid/veilid/-/blob/main/INSTALL.md

--
SugarBug | https://sybershock.com | NNTP | Usenet | Forum
Fediverse | https://syfershock.com/users/syfershock
NightBulb | https://nightbulb.net | Flip the night switch.

On Sat, 12 Aug 2023 03:07:11 -0500, Syber Shock <admin@sybershock.com> wrote:
>https://veilid

anything resembling "storefront" should be avoided like you'd avoid
the bubonic plague. see https://www.danner-net.de/omom/tutorwme.htm
>OmniMix * Tutorial * Whole Message Encryption (WME) PreviousTopNext
>It's obvious to prevent your normal e-mail correspondence from being
>spied on by encrypting it with PGP. If the messages include attachments,
>you have to encrypt those as well. But there are parts of your message
>you can't hide this way, like its size, the subject, some language
>specific characteristics, and last, not least the fact of sending a
>multi-part message. That's where OmniMix's 'Whole Message Encryption'
>comes to your aid.
>Different from PGP frontends, which only allow to manipulate your
>message before being sent by the mail client, a proxy server like
>OmniMix is able to alter it as a whole, as long as the result remains
>a compatible mail. Provided that the PGP keys of all recipients of a
>mail are available, OmniMix can be advised to encrypt the entire
>message, including the complete header section and some random dummy
>data to disguise its real size, into one single PGP message block and
>send it by means of a rudimentary header, which has to contain nothing
>but the mail addresses and maybe some 'X-Hashcash' tokens. If it's sent
>via a nym server an existing 'Nym-Commands' directive is also moved
>outside the WME encryption block, but for reasons of security this
>doesn't matter, as the message in any case is additionally encrypted
>with the server's key. For an adversary, who's allowed to become
>acquainted with the identity of the correspondents, the result of this
>procedure is nearly worthless.
>Moreover OmniMix even supports sending WME messages anonymously, which
>usually isn't done to hide your identity from the recipients within
>your WME community, but to prevent external observers from figuring
>out the communication partners. Keep in mind, that the data within the
>WME block aren't anonymized, but, though maybe shortened dependent on
>an active 'Mail Permits' header filter list, handled like normal mail.
>In order to allow an unrestricted, transparent communication without
>adverse effects for the participants, among other things there's still
>your 'From' address - which may be bogus - and the 'Message-ID'. If
>the former can be found on the WME recipients list with 'Sign'
>activated, the resulting signature may also expose your identity to
>those who are able to decrypt the message. So check what gets
>encrypted at the 'Data for Whole Message Encryption' section of the
>'Raw Data' list as well as the 'Log' entries to assure yourself that
>no sensitive data are unintentionally revealed to the addressees!
>Caution: Don't send an anonymous mail to several addressees at a time
>if you don't want them to become linked! In this case send a separate
>one to each of them.
>The recipients then either have to decrypt the PGP block manually and
>import the result into their mail user agents, which certainly can
>only be accepted in exceptional cases. On the other hand OmniMix can
>automatically translate the messages back into their original state
>in the course of its retrieval from the POP3 server, as far as the
>corresponding secret PGP key and the correct passphrase are placed
>at its disposal.
>At the 'Dummy Load' page of the 'WME' section you're able to randomly
>increase the size of your mail. This measure prevents adversaries
>from estimating the kind of message, whether it's about a usually
>shorter text or a more voluminous data transfer. Request a message-
>specific dummy load by sending the desired block size range
>('O-Wme-Dummy-Size-Min' and 'O-Wme-Dummy-Size-Max' header entry)
>with your message. Values higher than the maximum block size defined
>within OmniMix are refused, as the processing of a message extreme
>in size may knock out your system. OmniMix now appends a random text
>block to your message introduced by a line with a unique character
>sequence. The contents of that indicator line is added to the message
>header as the argument of an 'X-Wme-Dummy-Separator' entry in order
>to allow the recipient's system to restore the original message by
>removing the dummy load. It's important, that the dummy separator
>header is named equally at the sender and recipient, as otherwise
>the addressee won't be able to restore the original message.
> Pros and cons of different communication methods
> Ordinary PGP WME Remailing Remailing Nym Nym
> Mail + WME + WME
>Contents Protection No Reduced* Complete* No Complete* No Complete*
>Reply Capability Yes Yes Yes No Yes Yes Yes
>Anonymity towards an external observer No No No Yes Yes Yes Yes
>Anonymity between the correspondents No No No Yes No Yes Yes
>Latency Low Low Low Medium Medium High High
>Reliability High High High Medium Medium Low Low
> * Reduced: Net data only / Complete: Data + structure
>The first step to set up WME is to add all required keys to the 'WME'
>keyring ('WME' tab within the 'Nym Configurator'). You have to import
>public keys for your correspondents and one or more public / secret
>keypairs for yourself. Don't use any of your very secret PGP keys for
>that transmission purpose, as its passphrase has to be stored on your
>computer and both can be stolen by anyone who gets access! Better
>create new keys and mark them with names, that point out their low-
>security use, e.g. by adding the character sequence '(WME)' to the
>User-ID. As decryption problems can't be ruled out otherwise, it's
>recommended to create your keys within OmniMix itself.
>You may notice that the WME section offers a greater variety of
>partly more secure encryption and hash algorithms than allowed for
>nym accounts. That's because there's no need to consider the
>capabilities of remailers and nym servers.
>Next is to go to the 'WME' tab of the main window and add the mail
>addresses of all participants in your WME network to the list along
>with the corresponding key and - if it's a private key of your own -
>the passphrase. Based on this list, if WME is active, all mails,
>whether sent normally or by one of your nyms, are examined for the
>presence of corresponding encryption keys. If OmniMix finds keys for
>all 'To:' and 'Cc:' recipients and there are no 'Bcc:' recipients
>(who would be uncovered by an encryption using their keys), the mail
>gets encrypted and only header data mandatory for delivery are left
>outside the protected block. At request the sender's signature is
>added in the course of the encryption to prove the authenticity of
>the sent mail.
>Finally you have to tell OmniMix, who's allowed to use the single
>private key / password combinations to sign outgoing and decrypt
>incoming WME mails. Therefore go to the 'User' tab and mark for
>every user the 'WME' mail addresses that belong to that account.
>Now you've finished. All outgoing mails are processed dependent on
>the WME mode ('WME' tab, 'disabled' / 'enabled' / 'required'). If a
>message has to depart from that rule, then use the according header
>directive. 'O-WmeSend-Mode: required' e.g. rejects a message that
>can't be WME encrypted, with 'O-WmeSend-Mode: disabled' you would
>even be allowed to send a usual anonymous mail to someone whose key
>is present at the WME keys list. The 'Sign' setting within the WME
>participants list is binding in any case. Therefore, if signatures
>are requested, the WME encryption has to fail as long as the
>password isn't properly set for the WME key or the WME item isn't
>assigned to the user account.
[end quote]

OmniMix 2.6.8 (2022-11-27):
https://www.danner-net.de/om.htm
https://www.danner-net.de/omom/index.htm
https://www.danner-net.de/om/OmniMix_2.6.8_Uno_Setup.exe

On 2023-08-12, Syber Shock <admin@sybershock.com> wrote:
> The maintainer has released a Debian package repo for ease of install.
>
> Veilid: A secure peer-to-peer network for apps that flips off the
> surveillance economy:
> https://www.theregister.com/2023/08/12/veilid_privacy_data/
>
> [copypasta]
>
> site: https://veilid.com/
>
> Veilid (pronounced Vay-Lid, from 'Valid and Veiled Identification')
>
> Veilid allows anyone to build a distributed, private app. Veilid gives
> users the privacy to opt out of data collection and online tracking.
> Veilid is being built with user experience, privacy, and safety as our
> top priorities. It is open source and available to everyone to use and
> build upon.
>
> Veilid goes above and beyond existing privacy technologies and has the
> potential to completely change the way people use the Internet. Veilid
> has no profit motive, which puts us in a unique position to promote
> ideals without the compromise of capitalism.
>
> [/copypasta]
>
> Instructions to install a VeilID node
>
> https://gitlab.com/veilid/veilid/-/blob/main/INSTALL.md
>
Thanks for posting this, I appreciate it.

Happy Hacking
ReK2

--
- {gemini,https}://{,rek2.}hispagatos.org - mastodon: @rek2@hispagatos.space
- [https|gemini]://2600.Madrid - https://hispagatos.space/@rek2
- https://keyoxide.org/A31C7CE19D9C58084EA42BA26C0B0D11E9303EC5

On Sun, 13 Aug 2023 01:49:43 -0000 (UTC)
rek2 hispagatos <rek2@hispagatos.org.invalid> wrote:

> Thanks for posting this, I appreciate it.

You're welcome. If you are going to test it please do chime in with your
thoughts on its operation.

--
SugarBug | https://sybershock.com | NNTP | Usenet | Forum
Fediverse | https://syfershock.com/users/syfershock
NightBulb | https://nightbulb.net | Flip the night switch.

On 2023-08-13, Syber Shock <admin@sybershock.com> wrote:
> On Sun, 13 Aug 2023 01:49:43 -0000 (UTC)
> rek2 hispagatos <rek2@hispagatos.org.invalid> wrote:
>
>> Thanks for posting this, I appreciate it.
>
> You're welcome. If you are going to test it please do chime in with your
> thoughts on its operation.
>

I sure will, but I will most likely wait until defcon and then CCC camp,
to test it.

Happy Hacking
ReK2
--
- {gemini,https}://{,rek2.}hispagatos.org - mastodon: @rek2@hispagatos.space
- [https|gemini]://2600.Madrid - https://hispagatos.space/@rek2
- https://keyoxide.org/A31C7CE19D9C58084EA42BA26C0B0D11E9303EC5

Syber Shock <admin@sybershock.com> wrote:

>The maintainer has released a Debian package repo for ease of install.
>
>Veilid: A secure peer-to-peer network for apps that flips off the
>surveillance economy:
>https://www.theregister.com/2023/08/12/veilid_privacy_data/
>
>[copypasta]
>
>site: https://veilid.com/
>
>Veilid (pronounced Vay-Lid, from 'Valid and Veiled Identification')
>
>Veilid allows anyone to build a distributed, private app. Veilid gives
>users the privacy to opt out of data collection and online tracking.
>Veilid is being built with user experience, privacy, and safety as our
>top priorities. It is open source and available to everyone to use and
>build upon.
>
>Veilid goes above and beyond existing privacy technologies and has the
>potential to completely change the way people use the Internet. Veilid
>has no profit motive, which puts us in a unique position to promote
>ideals without the compromise of capitalism.
>
>[/copypasta]
>
>Instructions to install a VeilID node
>
>https://gitlab.com/veilid/veilid/-/blob/main/INSTALL.md

<https://veilid.com/Launch-Slides-Veilid.pdf> - Page 29 f.:

| Compiled Routes
|
| Private Routes are published as a ‘private destination’ and Safety
| Routes are allocated locally and combined together with a Private Route
| to form a Compiled Route.
|
| Each node hop only knows about the next one. This is similar to onion
| routing, but assumes that the source is fully in control of the Safety
| Route and the destination is fully in control of the Private Route

The SURB problem that already sandbagged Mixminion.

Thanks, but no thanks!

On Mon, 28 Aug 2023 11:28:17 +0000, Anonymous <nobody@yamn.paranoici.org> wrote:
>Syber Shock <admin@sybershock.com> wrote:
snip
>>Veilid (pronounced Vay-Lid, from 'Valid and Veiled Identification')
>
>The SURB problem that already sandbagged Mixminion.
>Thanks, but no thanks!

unfamiliar acronym (using Tor Browser 12.5.2)...
https://duckduckgo.com/?q=SURB

https://www.mixminion.net/
>Mixminion: A Type III Anonymous Remailer
>Mixminion is the reference implementation of the Type III Anonymous
>Remailer protocol.
>Note: Mixminion is not under active development, and probably will not
>work if you try to use it. I'd love for somebody to resurrect mixnet
>remailer R&D, and have some thoughts on the topic which I'd be more
>than happy to share. Mixminion might serve as a good basis for such an
>effort. But for practical use, it is not currently recommended. It may
>not build on your system of choice; if it builds, it may not work. It
>is not currently supported. Probably only developers, researchers, and
>anonymity enthusiasts should be trying it out. Good luck!
>--Nick Mathewson, August 2013....
[end quote]

https://en.wikipedia.org/wiki/Mixminion
>...Mixminion supports Single-Use Reply Blocks (or SURBs) to allow
>anonymous recipients. A SURB encodes a half-path to a recipient, so
>that each mix in the sequence can unwrap a single layer of the path,
>and encrypt the message for the recipient. When the message reaches
>the recipient, the recipient can decode the message and learn which
>SURB was used to send it; the sender does not know which recipient
>has received the anonymous message.
>The most current version of Mixminion Message Sender is 1.2.7 and
>was released on 11 February 2009.
[end quote]

storefront operatives have been hiding under every transparent rock

Sandbagged? Do you mean that it has some negative impact on speed and compute usage? Because I can't seem to find anything pertaining to an attack using the feature when I look it up.

If it's the performance stuff you're referencing then I don't see why that's a real problem. Trading off compute & speed for anonymity is fine.

On Mon, 29 Jan 2024 19:30:05 +0000, tl4h92+5vl0nig3ewwoc@sharklasers.com (carbon42) wrote:
>attack using

24 days . . .

D <J@M> writes:

> 24 days . . .

Let's pray that this wont turn into "-1 days" (and counting) to
celebrate each day GG being disconnected.

It already sucks enough.

--
I do not bite, I just want to play.

Ok ... this may at least automate it for everybody:

Custom epoch with (day != 1) ore even more generalised ones? #9
https://github.com/df7cb/sdate/issues/9

Peace! ;-D

--
I do not bite, I just want to play.

On Tue, 30 Jan 2024 10:42:39 +0042, yeti <yeti@tilde.institute> said:

> Ok ... this may at least automate it for everybody:
>
> Custom epoch with (day != 1) ore even more generalised ones? #9
> https://github.com/df7cb/sdate/issues/9

Why re-invent the wheel, when there's already a service that does what we
want already?

https://www.timeanddate.com/countdown/generic?iso=20240222T00&p0=1241&msg=Google+Groups+Shutdown&font=slab&csz=1

> Peace! ;-D
>
> --
> I do not bite, I just want to play.

Stainless Steel Rat

On Tue, 30 Jan 2024 10:42:39 +0042, yeti <yeti@tilde.institute> wrote:
>Ok ... this may at least automate it for everybody:
>Custom epoch with (day != 1) ore even more generalised ones? #9
>https://github.com/df7cb/sdate/issues/9
>Peace! ;-D

(using Tor Browser 13.0.9)
https://github.com/df7cb/sdate/issues/9
>Custom epoch with (day != 1) or even more generalised ones? #9
>Open drawkula opened this issue Jan 30, 2024 * 0 comments
>drawkula commented Jan 30, 2024
>Trigger:
>Can we please get an additional epoch for GG's "Usenet suicide"?
>Alternative:
>Would Unix seconds as means to define a different epoch work?
>Everyone could have any epoch then?
>(-: At least until someone demands nanoseconds as resolution... ;-)
[end quote]

seems confident that google will withdraw from the usenet field

On Tue, 30 Jan 2024 09:13:26 +0042, yeti <yeti@tilde.institute> wrote:
>D <J@M> writes:
>> 24 days . . .
>
>Let's pray that this wont turn into "-1 days" (and counting) to
>celebrate each day GG being disconnected.
>It already sucks enough.

it's a biblical two-mouthed gladius(double-edged sword) either way, seems
like their most convenient option is to run it through . . . only 23 days;
i'm only a layman but experienced user of usenet newsgroups, and what may
happen after google pulls the plug is a looming question that news server
administrators could be concerned about? but from what i've gathered from
reading their discussions in other mostly server-related newsgroups (e.g.
news.admin.net-abuse.usenet, news.admin.peering, news.software.nntp, alt.
free.newsservers, alt.privacy.anon-server), it's more like "wait and see"
because of so many factors involved . . . probably it will result in more
spam from non-google servers, but a significant reduction in spam overall;
ideally news servers that allow posting will make it progressively harder
to register for posting privileges, and more strictly limit cross-posting,
off-topic and other troll tactics that google groups became notorious for;
ironically, posts about google groups going away are universally on-topic
in all newsgroups because they have so badly spammed every busy newsgroup;
it will be interesting to see what happens in the wake of "google groups" . . .

On Tue, 30 Jan 2024 14:09:04 +0000 (GMT), Stainless Steel Rat <Use-Author-Supplied-Address-Header@[127.1]> wrote:
>On Tue, 30 Jan 2024 10:42:39 +0042, yeti <yeti@tilde.institute> said:
>> Ok ... this may at least automate it for everybody:
>> Custom epoch with (day != 1) ore even more generalised ones? #9
>> https://github.com/df7cb/sdate/issues/9
>
>Why re-invent the wheel, when there's already a service that does what we
>want already?
>https://www.timeanddate.com/countdown/generic?iso=20240222T00&p0=1241&msg=Google+Groups+Shutdown&font=slab&csz=1

very cool! (my local system time 00:00-24:00|MT/UT-7) . . .

(using Tor Browser 13.0.9)
https://www.timeanddate.com/countdown/generic?iso=20240222T00&p0=1241&msg=Google+Groups+Shutdown&font=slab&csz=1
>Google Groups Shutdown
>22 days 16 hours ... minutes ... seconds
>Time until Thursday, February 22, 2024 (Mountain View time)
>NOTE: Message provided by user. Create your own countdown
>Need some help?
>Related Links
> Calendar Generator � Create a calendar for any year
> Calendar for 2024 � Calendar with holidays for this year
> Calendar for 2025
> Holidays Worldwide � Holidays and observances around the world
> Date Calculator � Add or subtract days, months, years
> Duration Between Two Dates � Calculates number of days
>Popular Countdowns
[end quote]

The fun with `sdate` is ...

------------------------------------------------------------------------
$ git log -n1
commit c7d2daff128ed89c4a64ad6d235f15764e73e5f9 (HEAD -> master, origin/master, origin/HEAD)
Author: Jacob Moody <moody@posixcafe.org>
Date: Mon Sep 11003 10:07:39 1993 -0500

deb also needs libpam
$ ls -l .git
total 72
-rw-r--r-- 1 dodo dodo 96 Sep 11109 16:58 FETCH_HEAD
-rw-r--r-- 1 dodo dodo 23 Sep 11087 17:19 HEAD
-rw-r--r-- 1 dodo dodo 41 Sep 11109 16:58 ORIG_HEAD
drwxr-xr-x 2 dodo dodo 4096 Sep 11087 17:19 branches
-rw-r--r-- 1 dodo dodo 259 Sep 11087 17:19 config
-rw-r--r-- 1 dodo dodo 73 Sep 11087 17:19 description
drwxr-xr-x 2 dodo dodo 4096 Sep 11087 17:19 hooks
-rw-r--r-- 1 dodo dodo 23725 Sep 11087 17:19 index
drwxr-xr-x 2 dodo dodo 4096 Sep 11087 17:19 info
drwxr-xr-x 3 dodo dodo 4096 Sep 11087 17:19 logs
drwxr-xr-x 4 dodo dodo 4096 Sep 11109 16:58 objects
-rw-r--r-- 1 dodo dodo 796 Sep 11087 17:19 packed-refs
drwxr-xr-x 5 dodo dodo 4096 Sep 11087 17:19 refs

------------------------------------------------------------------------

.... thet e.g. `sdate bash` adjusts the date for all the subprocesses.

--
I do not bite, I just want to play.

Hearsay in the comments. I don't know if it is true.

iPhone only

Looks like the initial rollout of Veilidchat is by invitation through the Apple store.

Probably sometimes in February I'll take a look and dump in a test OS.

On Thu, 1 Feb 2024 21:08:17 +0000, Anonymous@www.rocksolidbbs.com (Anonymous) wrote:
>Probably sometimes in February

21 days . . .

When you are a hammer everything looks like a nail.
Every so often a white paper comes along with some network. Nobody has actually shown how it scales. I have 10 routers and this is how it looks like. With 50 that is the model. I don't need FFT (Fast Fourier Transforms or LaPlace) but really you need to check your comm module before you come out with networks.
For i2p models I use radio relay and truncated Planar Wave (in my blood) models. There are more complex and better models but the processing power is just to much.