Built-in, best effort, chat module

[dpc]

Censorship resistant, redundant, lightweight, built-in (zero-additional infra needed). Good enough for many applications and small communities.

• Guardians set memory limit for pending messages "chat mempool size" (eg. 1GB).
• Limited message size (512B?). (Edit: well, should be enough to share a serialized Bag, I guess)
• Sending users post messages encrypted to public key along with a fresh PoW. Only highest PoW messages are kept with a PoW decay.
• Sending users post to multiple peers for redundancy.
• Receiving users post a signed request and a PoW. Periodically check peers in a round-robin fashion.
• On successfully returning to the receiver, messages immediately deleted.
• If message posted with too little PoW, rejected.
• Messages get dropped, so client module needs to re-submit periodically to peers.
• No persistent storage involved to make it resource-light. Benefit of being redundant.
• No Fedimint consensus involved.
• Peers don't replicate between each other for simplicity.
• Very best effort, but simple and good enough.
• If delivery confirmation is required, can be done by the receiver by posting a special ACK message. Peers (relays) don't care.

Could be done a hackaton project really. A hashmap with some crypto and PoW. The UX might be a bit sucky for a general purpose chat, but for two people trying to share a QR code like a payment request, might be just reliable enough.

[elsirion]

Relevant xkcd

[dpc]

But, but... :D

I don't think about it as a standard, but a purpose-built app. AFAICT there are 0 explicitly Federated chat systems/apps, so all the existing ones do not take benefit of the existing redundancy and trust model, while introducing centralization aspect.

[tvolk131]

I don't see anything listed that couldn't be solved by Nostr relays (please correct me if I'm wrong 🙂). Nostr messages can be posted to multiple relays, providing redundancy. They're signed using the public/private key pair of the Nostr user. Relays can each have their own data retention policies, size limits, etc... NIP-13 defines a standard for PoW.

It could be cool to allow for federation nodes to each be able to advertise a relay that they run to allow a sort of "protocol transfer" to Nostr which can then handle the use case you're describing.

[elsirion]

I tend to agree (even though I tend to strongly dislike nostr design choices). Related to #1604 (comment)

[EthnTuttle]

Custom relays are not prohibited, just frowned upon by certain people. Really comes down to client adoption in some ways. It's all beautiful chaos anyway.

[dpc]

I'd like the whole thing to work through the same jsonrpc apis that Fedimint uses and not involve any extra infra. For this reason alone it's not going to be nostr.

Under the hood it does work like every guardian being a nostr relay, but that's not exactly revolutionary.