pull down to refresh

https://sendwyrd.com/w/hSRYpR29huivOT9L#3nFeyyH8anJTcmgeLxwzjovn-cBN0JWtQtT1Rw9Mcwg

Spent a little over a day building this tool, which is an identity-less and platform-less social messaging protocol and service. It is sort of a wrapper on messages, so that messages become objects that are platform agnostic. "Isn't this just...?" Yes, this is not some mind-boggling new thing, but it has some subtle nuances to the design that seemed interesting to me. Maybe you will find it useful?

The thing that I think is particularly neat is you can begin using it today, unilaterally, on any and every platform that allows posts/messages, so there is no network bootstrapping required for usability.

More detailed philosophy/about section on site: https://sendwyrd.com

159 sats \ 1 reply \ @Scoresby 27 Apr

This is cool. It's a different form factor than I'm used to thinking about with messaging (Anyone with the link can read, only people with the link can read).

It would be kinda cool if this was trivial to host, so anyone could use the same code, but send links from a domain they control.

reply

I considered briefly letting people run their own hosts, and that might be next step. Open sourcing the protocol, maybe even all code, so anyone who wants can run their own, and allowing them all to be cross compatible.

So far it seems no one is really interested in the idea though, so might just hold off. I am not a developer, so I thought it was cool to be able to put together a working product with Claude in just a couple days! I'm not sure what the future of cyberspace / coms will be, but it seems everyone has the sense that human computer interfaces are about to become rather different than the way they are now.

I might leave it alone for a bit, maybe annoy various friends by using it unilaterally and see if anyone else starts playing with it.

reply

I like that the decryption key is in the URL fragment that means the server literally can't read your messages since browsers don't send the # part. That's a clean way to handle it. How does the expiration work on your end? Does the server just delete the encrypted blob after a set time, or is there something built into the encryption itself? And I'm guessing there's no real way to stop someone from just copying the text before it expires right?

reply

Yeah. The server will delete after a fixed amount of time that the user sets (default is 90 days), or if they request a burn. There is also an option to never delete. This could be neat for nostr since deletion on nostr doesn't really work. Correct, anyone can copy it while it's live -- my thinking was this replicates human interaction in terms of social discretion around things like rumors, strategy, etc.

I considered briefly letting people run their own hosts, and that might be next step. Open sourcing the protocol, maybe even all code, so anyone who wants can run their own, and allowing them all to be cross compatible.

So far it seems no one is really interested in the idea though, so might just hold off. I am not a developer, so I thought it was cool to be able to put together a working product with Claude in just a couple days! I'm not sure what the future of cyberspace / coms will be, but it seems everyone has the sense that human computer interfaces are about to become rather different than the way they are now.

reply

Really neat approach to solving the network bootstrapping problem. Excited to see how those subtle design choices play out in practice

reply