Introducing Pulsar a private nostr chat app that protects your metadata.


Pulsar was originally prototyped by supertestnet and I joined him a few weeks ago to build out the frontend and add all of the basic features to reach an MVP. 


Pulsar is a simple nostr group chat app that aims to follow best practices to secure all of the data and metadata associated with a chat instance.
Here is how pulsar protects your privacy:
  • Each chat instance is encrypted with a shared secret that also acts as an invite for others to join the chat group and decrypt the messages
  • Each real keypair of the participants in the chat instance is wrapped in an ephemeral keypair (which is what is broadcasted to the relays)
  • All messages are encrypted by default with the shared secret using the ephemeral keypairs
  • A fresh ephemeral keypair is also created for each message
  • All messages are padded with garbage data to give them each the same length
  • Additionally a padded / encrypted message is posted every 3 seconds while the instance is open (this is the pulse) which prevents outside observers from identifying the real messages AND when real messages are posted
  • Note that Pulsar MUST be used with Tor or alongside a VPN or you will leak your IP address
Personally my final ideal state for Pulsar would be a Signal like experience with the same privacy guarantees but without the need to provide a phone number. Pulsar is still very much in early alpha phase, the code is a little messy, but it works as expected. If people like this approach I plan on rebuilding Pulsar as a native app, but for now it will live as a simple web app.
Thanks for reading and please provide any feedback you have or issues you experience while using Pulsar.

Onwards!
Badass! There goes my day then...
reply
Is this the same implementation that Amethyst, Snort, and Coracle are using and working on to solve the same issue?
reply
No, it's a different construction
reply
I don't think
reply
Nice! I am very interested in DMs on nostr. We might use nostr DMs for DMs on SN when NIP-44 is merged.
Additionally a padded / encrypted message is posted every 3 seconds while the instance is open (this is the pulse) which prevents outside observers from identifying the real messages AND when real messages are posted
If you want to create noise to hide the real messages in, you should post these fake messages in random intervals. If you post it every 3 seconds it could be trivial to filter the fake messages out.
And I tested it out but my messages just disappear: https://files.ekzyis.com/public/pulsar.mp4
I then reset Alby for this website and tried again and then it worked. Maybe I clicked on cancel in some prompt or something, idk
reply
you should post these fake messages in random intervals. If you post it every 3 seconds it could be trivial to filter the fake messages out.
How is it trivial? All messages are sent in those 3 second intervals. There are no "in between" messages. When you send a real one, it waits til the next fake one is supposed to go out and then takes its place.
reply
Ah, oh, didn't know that. But doesn't this make the chat slow? I assume it's 3 seconds per message per group (and not per sender) so in a big group, a lot of real messages would get queued up, no?
reply
It's 3 seconds per message per sender
The delay doesn't seem noticable unless you compare side by side
But it would probably get worse in a big chat with lots of people
reply
Thank you, and great feedback!
I think that's a good optimization to make, randomizing the interval of padded messages (though we would still need to keep it within a tight timeframe 1-5 secs)
Looking into this issue now, did you close the browser right away after the message didn't come through, or wait a few seconds?
I imagine it could be the relay connections spinning up quick enough
reply
Wait nvm it looks like the issue is the extension didn't popup before you entered the chat so you were able to enter without a real npub, making a fix now!
reply
I think the extension just didn't popup because I already tried it before and clicked on "remember my choice"
I thought I just clicked on cancel + "remember my choice" so it did not have permission and wasn't able to prompt me anymore. Would at least be the easiest explanation
But just tested it again and it didn't work even with giving all permissions. Will record a new video now with the browser console open
update: mhh, wasn't able to reproduce. Works now: https://files.ekzyis.com/public/pulsar2.mp4
reply
This solves the metadata issue of Nostr DM's perfectly.
reply
Personally my final ideal state for Pulsar would be a Signal like experience with the same privacy guarantees but without the need to provide a phone number.
I'm glad to see this. Non-social-media apps are going to be the killers apps for Nostr. A Signal-like app will be the most important.
reply
We should call Non-Social Media apps, Anti-Social Media for the hell of it.
reply
Am I reading github correctly? All of this was implemented using only HTML & CSS?
If so, I can't get my head around that (yet). (But I've seen what @supertestnet has done before, so I'm intrigued to say the least.)
If not, what am I missing?
reply
It's only made of html, css, and vanilla javascript that runs directly in your browser
The javascript is embedded in the html so github doesn't "count" it even though it's there
reply
I picked that up when going through your code, but only after asking here.
Thank you for responding. Much appreciated!
reply
Great but my fear is about relay overload. Won't this type of padded/fake/encrypted message overload the relays ?
reply
To quote the nostr GitHub: "there will always be some Russian server willing to take your money in exchange for serving your posts"
We're using similar padded/fixed-frequency messages as simplex uses, so if they can do it, I think we can do it too
reply
Nice ! Very awaited nostr feature, encrypted group chat over nostr ! Sorry for the maybe obvious question, but is it all client side are does it rely on your server? I mean could this app goes down if your server goes down or is it directly broadcast to relays without third party in-between ?
reply
It does not depend on our server, you can even download the client app and self host it (it's just an html file). All messages go directly to relays with no third party in between.
reply
Then this is amazing thank you ⚡⚡⚡ It this a tech that any nostr client could implement potentially ?
reply
Yes, the code is FOSS so anyone can implement
reply
One thing in term of UX that I'm struggling with is that each time I leave the chat, I have to enter again the chat string to access the chat again. Am I doing this badly or is there a way to not have to enter the "generated chat string" again after leaving ?
reply
There used to be a screen that saved your chat strings as cookies and allowed you to name them and tap/click them to re-enter but Austin got rid of it for now and wants to add it back as a native-app-only feature
He is concerned that if you save any cookies, any browser extension you have installed can read your cookies and thus compromise your privacy (e.g. by decrypting all your messages as well as everyone else's messages -- your chat strings are also your decryption key)
reply
👏👏👏Congrats on the release!
reply
Very cool - agree with other poster who mentioned random intervals in the pulse
reply
reply
As was mentioned by the other person, if the pulse is at regular intervals, in any pattern, spotting other traffic would be one trivial. If the pulse was random they'd never be able to tell what is real and what is noise
reply
I've now seen a response to that which makes sense too
reply
for mixing anonymity and max efficiency, what about every three seconds all messages sent over this protocol are batched and sent. Then each message sender only has to wait for the next 3 second transmission "train" to leave the station for the message to send. Then each relay only has a note every three seconds that encompasses all pulsar messages. Is it possible to nest the encryption to make something like this possible?