For future-proofing, both of these are probably terrible ideas :)

I assume you mean because of size limits. As of right now, the current number of milliseconds since the epoch only takes 6 bytes to represent; to be exact, it’s less than 8.9e-8 of the max that 8 bytes can represent - so basically safe for all eternity IMO.

As for the group size, I know that some rooms in chat systems such as Matrix and Discord have more than 256 members, but my stance is that E2E encryption is useless in that type of situation because there is no way you personally know and verified all those members, so your chat is not private anyway.

Not sure if that’s good or not. That’s one of the problems with email, leaking so many addresses in the CC field (that’s why we have BCC). Spam protection is hard in p2p networks, but i’d imagine that by “threading” discussions you could generate specific keypairs so that if some spam starts flowing in your direction from a discussion you can just drop that keypair (like email aliases).

Well, you can easily generate multiple key pairs and use them for different rooms, similarly to email aliases. I’m not concerned about the fact that it reveals all recipients to each other, because the point of this feature is to emulate group chats, where that’s desired. If you want to send a message to multiple people without revealing the full list of recipients to each of them, you could just do that (just send the message to each of them with empty other-recipient lists).

That’s pretty cool. Have you considered using I2P or an even-more experimental mixnet (like katzenpost) as transport layer?

We did, early on, actually. I wanted to use Tor as a transport, an idea I borrowed from Tox (which makes no effort to provide anonymity and suggests running it over Tor if you care about that). A friend of mine, one of the two other people involved in the planning, wanted to roll our own similar system. When she convinced me that hers had an advantage over Tor’s (nodes cannot tell if they are the first relay in the chain or not), I conceded on Tor and wanted to use GNUnet as a transport, but sadly accepted that GNUnet is vaporware and we couldn’t depend on it, so I ended up implementing roughly my friend’s suggestion.

We didn’t look at I2P or katzenpost in particular. I had sort of gotten discouraged by the feeling that there were too many interesting dark/mixnets for me to investigate and I wasn’t confident enough in any particular one to want to use it as a transport.

Thanks for the read I’ll finish tomorrow (getting late). In the meantime, are you familiar with the Briar? They also use some gossiping (wifi, USB keys…) as well as onion services to broadcast messages.

Briar was one of the apps I looked at before deciding to make one. The main reason I wrote it off was for requiring a phone. It’s definitely possible that it has some ideas we should borrow, but there were too many of these secure messengers for me to look at all of them in detail.

Update: I contacted an author I respect, Drew DeVault, for feedback on the protocol and he said that sending the recipient ID in plaintext was bad and that we should use some form of onion routing instead. To be honest, I think this is an upside of Tor compared to my friend’s idea that we totally overlooked - that the first and second relay nodes don’t know the final recipient, whereas in sufec they do - so we might change course and do something like that after all.