SimpleX is based around queues. Instead of pushing everything to a relay and have it stay there forever, you push messages into a queue that eventually gets consumed by the person you’re sending the messages to. They exist on the relay temporarily and they are encrypted. Cool part is that there are no long-term “addresses” or “pubkeys” to send the message to, so spam is much harder. I think nostr could learn a lot from this protocol, I believe we can use something like this to strengthen use cases on the nostr side. I am building a SimpleX rust library to learn the protocol further, and will be looking into how we can leverage it in our apps.

Replies (77)

From the top of my head: Client -> Relay: ["PUSH", <filters>] / ["PULL", <filters>] That with event kinds specific for this, probably in the 2k/3k range? Something that doesn't stick around forever, but can be deleted when someone comes to PULL the queue after someone has PUSHed into it. It'd be an interesting concept to explore.
I love the fact that SimpleX puts users (and their queues) at the center of the universe. Whereas with nostr, users are at the mercy of popular relays.
Nostr was designed for public stuff. I think it makes sense to leverage other protocols to add private comms in clients. Looking forward to seeing what you come up with.
Default avatar
Nostr OG 2 years ago
The dev looks like a trove of high level ideas. Impressive.
n's avatar
n 2 years ago
🫂
fractalchris's avatar
fractalchris 2 years ago
That's what I have! But I still haven't set up my SimpleX relay.
Ben found a bug in damus zaps, im fixing it now. Noone should be able to fake a zap to my own post, so this is new!
The metadata protected E2E messaging in xx network takes a similar approach. It stores for a set period of time (21days) since it can't be known when the recipient receives the messages. It's definitely the right design for private messaging applications.
Bogdan Zurac's avatar
Bogdan Zurac 2 years ago
But what's wrong with having the messages stay on one (or more) relays for a long period of time? That allows you to switch devices and preserve your historical messages, right?
J'espère que toute la communaute des informaticiens savent que vous êtes competent et ne restez en place à tourner en rond. Merci vous avoir lu lors de vos interactions entre Jack NVK et tant d'autres en décembre en décem'''sur Twitter e je mettais dit ce gars est un bon gars qui a de la suite dans les idées... Continuez comme ça en toute amélioration continue >Qualité en normes avec vos pairs. 🙏
Nice! Do you need help on building the rust @SimpleX Chat library? I am experienced in rust and would love to contribute. Is there a public repo up already?
Maybe nostr encrypted group chats based on this model for privacy, and a classic nostr approach for more persistent content on the social media part ?
Considering anyone can run a relay in Nostr, it's pretty much impossible to have a "consumable". The encrypted message has to be assumed to live on the internet forever. Best Nostr can do is try to obfuscate sender and receiver from the relays.
Default avatar
nobody 2 years ago
If you can fix the only being able to use it from one device issue, this will be viable.
Agree but can't help but notice this. Something is off here unless someone zapped you $30 million with in btc image
like not having "#e" as a key be a thing needed for core functionality??
Its this a good app to use? I have to send a code to anyone else with the app? I wonder how good the encryption is
I've been using nostr:npub1exv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csm7d828for a couple of weeks now and so far the experience has been quite impressive. I especially was surprised that the audio quality is as good as it is... If you haven't tried it yet, you definitely should... View quoted note →
I like this idea too, "a dumb server" and how it is working with Simplex. At the same time the other way to go is simply run your own server and the Matrix protocol does this well. I think more energy needs to be put into helping non-techy folks run their own servers.
Are clients verifying the authenticity of zaps? Probably not, it is too cumbersome. Cashu-based zaps would probably make that much easier..
Gossip (in nostr-types) is apparently not doing it sufficiently. Looking over NIP-57 again, I'm seeing things I don't recall when I wrote the code. I'll get this issue fixed.
Verify the p tag, find its metadata, fetch its LUD address, extract the pubkey from the HTTP response and then validate the zap pubkey against that? I guess it's not that hard, but if the zap provider pubkey was included directly in the receiver metadata that would be much better.
This ^^ , for sure. It also seems to be an issue with hypercore chats like keet. The only 'one device' issue, unique key thingamagjig.
Default avatar
nobody 2 years ago
yeah, that's just what everyone needs. more standing in line and waiting their turn in the bread lines. hyper sanitary order is a collection process for fascist governance, not for useful and organic evolution. by forcing slow paced excessive order and compliance to be sure no drop is spilled - it creates the very lack of freedom which was the antithesis of the idea for tracking pow in the first place.
How do I open "note1e39qw85pajrud6s5pwzdsp6shnwfdgzg6qwhcsvxdglmmswnedds9jq2vv"?
Seems like a similar situation to torrents and p2p file sharing. Practically unstoppable. Also, hoping this happens too: note1d75r7ez8gkejh92nfyaq6r20eklj4wdn8jvvngrljupcqc9rphmsuxyk8a