Thread

The difference is that because they expose this very simple compatible interfaces the access to these websites becomes very programmable and allows clients to do crazy things like connect to a bunch of different websites and fetch only a specific common part of them, then mash these things together, fetch other related things from other websites and display the result (plus a ton of other possibilities).

Instead of having little "trending" sections at the corner of apps or stuff like that we could just have some configurable (with defaults perhaps) relay feeds.

Why do we need a second bad browser and a dumb standard when we already have proper browsers and W3 standards? The key word here is "why". What does "dumb" Nostr with its buggy, useless clients actually give us? The moment it steps onto a field where "grown-up" standards operate, it not only contributes nothing — it outright loses. In speed, in integration, and in purpose. You're literally saying that JSON with tags can be used for something serious, even when clients are forced to duplicate the letter case of tags because people are somehow even dumber than Nostr itself. Nostr only works well for the very thing its name refers to. And I don’t see anything like "and also a great tool for standalone solutions" in there.

You don't need Nostr for that. People do it without Nostr already. They use bits of design, code, load data. Why the hell would I need Nostr for this if I still have to monitor everything myself anyway.

Good rant! Agree nostr is the best tool in the box for a pretty limited range of use cases, mainly when you need an API that does its thinking out loud. When nostr tries to be what it isn't, that's when it gets super buggy and crashy. Like this idea of using nostr for the backend of a high-throughput video streaming platform with client-side proof generation, what on earth?

Why do you say it loses?

I am not aware of people doing it at all, so I have to assume you have the wrong "it" in mind. What are you thinking about here? I am talking about automating following updates from people on different websites (relays), automating fetching opinions about some other thing from different relays, automating publishing to different relays, automating discovering new content and new relays etc. Also let me know what do you think Nostr is good for then, and why you're here.

Nostr is good in situations where you need to transmit some stuff through a relay without asking anyone's permission and without any guarantees of delivery or receipt.

Sad answer, for a moment I thought this could be a fruitful discussion, but you didn't even answer my other question.

Rare

You mean

zap.stream

zap.stream - Nostr Live Streaming

Nostr live streaming powered by Bitcoin lightning. Stream freely with Bitcoin payments, no censorship, open source.

? Did you even bother to ask how it works before making this snarky comment? It is not using Nostr directly to transmit the video. Nostr is only for the social announcement, discovery and interaction. Can you provide another example of when Nostr gets super buggy and crashy? I mainly want to understand what you think Nostr "is".

i'll avoid the cross-examination and just say that nostr would be a beautiful thing if was only kind1 text notes, and outbox, and throwaway-ish nsecs, and that's it. Maybe media and blossom too, but honestly without media it'd be better, a unique text-only space. Fun, ephemeral, cheap, different, scalable. just think how beautiful that would be.

Then you add a link to your livestream URL on your kind1 text note, now what?

they you've added a link. you click on it it goes somewhere.

Then someone makes a client that parses all the notes for links of a certain flavor that indicate they are livestreams and starts to display those livestreams in a special way. Or someone makes an app dedicated to viewing livestreams from people in your Nostr network, then replies to that note announcing the livestream are displayed in the special livestream app and so on.

I understand that your vision of Nostr is broader 🤔 But every time I want to use Nostr somewhere, I just don't see the point in it. Right now I want to launch an internet radio, and it will have Nostr, but it's not needed there at all. I'll just add it for the sake of it, but it won’t provide any real benefit.

Good for them, but that's not nostr, it says so in the NIP01 brochure. Think about it. A fun space that isn’t trying to be twitter (it being text-only would make that point obvious, if people know not to expect pictures and videos and link previews they won’t feel they should expect other things too). And that has a personality, and that scales, and notes really are 100% self-contained. And you really do own your profile but nobody cares about some lifetime web of trust building nonsense, if you lose your nsec no big deal jump back with a new one, a whole fun culture evolves around nsec respawning, you don't need FROST or some other nonsense just to keep your nsec safe forever, nobody cares about that, that's not what this thing is. And super cheap, cause no media. No CDN of any kind. No DMs of any kind, no giftwraps, no MLS, no quirky relay auth, none of that, just kind1 text notes, shortened text links, and outbox, and nsecs that nobody cares too much about losing. I honestly think that ridiculously simple nostr could scale to 100 times more users that this nexus of complexity we have now.

I think you're describing a specific app more than a protocol. I think it would be cool, but at every point in your vision there will be people wanting to do something slightly different, and I think it's nice that the protocol is flexible enough to support these things. And we could just say "no, that is not Nostr", but then people would do the things in a worse way that isn't interoperable and creates centralization that may be fatal in the long term (it is happening everywhere already, but much less than it would if there wasn't a culture of standardization and interoperability around). Maybe you don't care about any of that, but I do. Anyway, Nostr can be used just like you described and that doesn't hurt the other use cases, nor vice-versa (maybe a little bit, but that's inevitable). In any case, I personally think the vision you describe (even if I think it's cool) would have much less appeal (can you imagine? even less than today!) than the current idea of a multimedia everything-interoperable Nostr, and, given that Nostr needs 10000x more people than it has today in order to be useful in any way to the world, restricting Nostr to that (even if it was possible) would be a bad move.

i mean anyone can do anything. but if the protocol sets clear limits then it becomes pretty hard to ignore those. Any nostr dev can rename "kind1" as "type1" in their events, but how far is that going to get them? And any web dev can create a chrome extension that turns all text into comic sans, but nobody is going to consider that as anything other than some dev hacking around. At this point it's late, you'd have to fork current nostr to make this ridiculously simple nostr with these limits explicitly spelled out in the foundational docs. and not respecting them making you seen as clearly not part of it by the gang, just an outsider doing their comic sans thing. text-only super-simple nostr would have appeal, seriously! people are sick of multi-media. people are sick of memes. and videos, and and gifs. and soon nobody's going to know what's AI slop and what's not, making them even more sick of media than they were already. text-only, it's the perfect fit for nostr and also for where we are in society right now.

There is a difference, if they renamed "kind" to "type" their stuff would not work anywhere else, and no one wants that so they don't do it. But if I said "Nostr is just text" but someone added a picture URL as text and someone else rendered that automatically that wouldn't prevent their text URLs from being shown in other clients. I'm sure you get the difference. In this case what would happen (if I'm right in my assumptions, and unfortunately) is that most users would migrate to the client that displayed the images and not just the URL text. Maybe you wanted me to write in the protocol that URLs are forbidden entirely and content with URLs must be treated as invalid. That could have worked for a while, but relaxing assumptions is a developer's primary ability (Postel's law, that's how protocol bloat happens always -- just take a look at any JavaScript codebase and see how they check if a thing is not null, then if it has some property, then some sub-property, then if it's a function, then call it while catching exceptions, then check if the returned value is of the expected type and so on). Also someone would end up introducing some weird roundabout way of sharing images without encoding them as URLs. If you look at twtxt (which is closest to your dream of pure text) even with the very few users they have they have already developed twtxt "extensions" (not hosted in the original twtxt protocol description page) that support mentions, threading, reposts, probably images and, who knows, maybe they even have livestreams there already.

If you'd have written that nostr is text only then it would be text only right now. I think you're underestimating the power of founding limits and consequential social enforcement. All the limits that you did set at the start are still respected. I'm saying it's way too complicated now. First you get DMs, and that means encryption, and that means losing your nsec becomes a bigger deal, and that means we need remote signers and bunkers, and it goes down and down in a spiral. What was stopping DMs from appearing in nostr? If you'd have said at the start "nostr is strictly not intended for encryption or DMs" in some very clear way then there would be no encryption or DMs right now, I'm pretty sure of that. And media, the moment you allow images and video you have CSAM obligations, and CDN serving, and centralised media hosting, and notes loading the text part and then 5 seconds later loading the image part and pushing the text part 10cm down the screen, and media rot and the whole core idea of a note being self-contained no longer applicable, and on and on. Nothing attempted to stop media from appearing in nostr. But if you think about it media and DMs are a kind of poison.

I did say clearly and explicitly that Nostr shouldn't be used for DMs (I did it in the Nostr Telegram group at the time, that had like 20 people, of which maybe 5 were the only ones really interested in Nostr). Still @Ben Arc made the first Nostr client with DMs after I begged him not to. Will this clear fact make you reconsider your position? If that isn't enough you can also take into account my twtxt example. If I make an effort I can probably come up with many other things that I think Nostr shouldn't have but that now it has standardized just because not having a standard would be worse as people would do it anyway in less interoperable ways. I never said Nostr shouldn't have images, because that idea didn't occur to me and I don't think images hurt that much (you can always opt to not use them yourself, and not associate with people that do), but I'm sure Nostr would end up having images if it had grown to more than 40 users anyway.

@Ben Arc You. You did this.

Images trigger CSAM obligations, CSAM obligations make it super hard for small players to scale. Also images lead to video, and video (especially bandwidth) means everything starts to cost a lot, hosting and CDN serving naturally starts to centralise. For text-only nostr, really anyone can join in on the infra side, it's so insanely cheap. Unrelated, but if you could go back in time would you still call it nostr? If not, what would you call it instead?

What do you think it should be called?

The Toaster Protocol Trusted and Open Association through Signed Text Events on Relays. Tempting to just go for it. Only kind1 text notes and Outbox. No DMs, no media, no zaps, no reactions (replies only), no link previews (shortening only). The only thing I’d add is Falcon keys for post quantum, swap out ECDSA. Because I think it’s kind of wrong to build anything brand new in 2026 on ECDSA.

BIP-340 is not ECDSA, but sure, Falcon whatever, there won't be any quantum signatures breaking ever. You should make Toaster as a subprotocol of Nostr! Make some relays that rejects anything that isn't pure text and a Toaster client that connect only to such types of relays. I can run one if you want.

Deal. Coming in 2026.

Great! If you don't do it I will.

Dms are good, so are images, stop being a misery guts.

Precisely. As for DNS, its installed base is the only excuse for its perpetuation. Public/private key pair signing is the only non-client server option that remains. Sensible move decentralising the NIPs, well done.

main obstacle to a practical implementation of DMs on a network of intermediaries like nostr relays is not really any different from any other thing. you can do MLS using ephemeral events, as one way, though it has scale limitations, the way that doesn't is where relays enforce privilege to restrict reading private events to authed users. i have been hammering at this last point for the last 2 years but nobody seems to listen to me. fortunately, my relay implements it and there is a growing number of users who have in mind private network deployments that can also be easily bridged to open public access as well as respecting the confidentiality of the operators of this network. the liveness problem of private communication for methods like MLS make it a lot more challenging than it would be with a dedicated protocol, and i just think that the lack of DM support is the number one thing retarding nostr adoption.

Nostr was never conceptualised for DMs. If you trust the concept for something then use it for what it was conceptualised for. DMs add a need for assured delivery that wasn't there before DMs add a need for encryption that wasn't there before Encryption adds a need for derived identities that wasn't there before Encryption adds a need for nsec hygiene that wasn't there before Nsec hygiene adds a need for remote signing that wasn't there before DMs add a need for relay specialisation that wasn't there before Relay specialisation adds a client UIs that wasn't there before The list goes on and on. DMs are a trojan horse, let them in and soon the city gates are open for an horde of barbaric complexity to march through.

the majority of non-competent distributed systems and game theory talkers who get all the airtime on this protocol don't actually understand either game theory or distributed systems. here's some hard fax: fully anonymized, private direct messages can only be coordinated over an anonymising proxy, with ephemeral messages, and thus have a huge problem with asynchrony and there is basically ZERO consistency to the data on the network. every security and privacy (a form of security policy) system has tradeoffs. the great holy grail of these uneducated, uncreative folk who say nostr can't do secure private messaging, is a type of privacy protection that is essentially a form of deliberate amnesia with a zero time window. the biggest disagreement i have with this idiotic view of what must be in place for nostr to implement this, is this: nostr's middleman, rendezvous architecture is designed for asynchronous messaging. but it can also do synchronous messaging through rendezvous, and solves the NAT routing problem that persists for anyone wishing to do p2p protocols from their home connection. nostr solves that problem. now go back to all these supposedly "private" protocols. NAME ONE THAT DOESN"T INVOLVE THEM CACHING YOUR MESSAGES ON THEIR SERVERS! not one of them. simplex, signal, matrix, telegram, whatsapp. all of them basically have relays in them. so, what was that you were saying? are you saying i can trust Signal Inc. more than i can trust my friend in germany?

I've no doubt that cryptographically-signed JSON events on websocket relays can form the basis for many neat things. As for Nostr, we have a long list of nostr protocol DM implementations (and nostr-inspired other protocol DM implementations). We can add to that long list, but for what? Nostr doesn't have a mechanism to sort this all out. There's no Supreme Court. There's no Jedi Council. It's XKCD 927 all the way down. 1. All solutions to the DM problem require widespread cooperation 2. Widespread cooperation at this stage is effectively impossible You see the meaninglessness here? If there is nobody to clean the wall then the moment you allow people to start throwing spaghetti at it it's over.

in government statute books, there is always a preamble which states the aspirational result of implementing the law. a bit like the aspirational preamble that you all have accepted as the premise of nostr. meanwhile, the lawyers pore through those things, and with enough time, will find a way for you to break the law without breaking the law. the same applies to nostr. what you think it is, is one thing. what it actually is, is something a bit more complicated than this uneducated faith in the preamble of a body of rules. that's why we don't have DMs still. because y'alls don't understand what the protocol allows. same goes for name/npub mappings and namespace registration. nostr protocol is not a complete distributed system. it's lego bricks for foundational components. you have to use your imagination and logic to see whether or not it can protect privacy adequately. most of it falls to the lowest rung of dev skill in architecture, the client devs, and idiot projects like primal promote these guys in front of us relay devs, who actually have at least one level higher knowledge of how this works. you should be listening to us, and working with us, instead of pretending that relays aren't important. or you can just go back to mastodon or bluesky or x and get off my lawn.

i don't think so. i can store privileged messages on my relay already right now and nobody authed to a pubkey that doesn't appear in my privileged message p tags can read it. i also have automatically configured relay whitelists that grant write access to anyone i might want to have an ongoing DM with. the only thing holding this up from working is a client that lets you configure it correctly to push events there correctly according to what i have configured. the rules for defining that, are not complex, and currently, almost no nostr clients implement this part of the protocol correctly. everyone loves their chosen single kind 1 client, with half arsed DM support, or irritating high friction like coracle, which works, but nags you without option to disable the nag that you are using nip-04, which btw, is not actually in practical terms any less secure, but is also a lot faster because everyone has AES acceleration even mobile users, a cipher stream algorithm that is standing up perfectly well to attacks everywhere on the internet over TLS. because of this downer negative pessimistic attitude, promoting the ignoring of this critical feature of a social network is the norm, and nobody has actually spent enough time to fix it. that is all. so it's a self fulfilling prophecy when you parrot these dictums about nostr "not being made" for something. perhaps we should talk about the fact that humans are "not made" for any specific thing either, yet can do many many more things than your little short circuit evaluation gives you.

I don't think it's a downer attitude or a self-fulfilling prophecy. It's just the physics of human nature and governance (or lack thereof). If you're designing a building you're not being a downer if you take into account gravity, you're not being pessimistic if you inform someone that their proposed balcony design just can't be built. You won't get this new standard widely adopted. It sounds really well thought out and could be the basis for a personal or other fork. But you won't get a critical mass of clients and relay operators on board. Nobody will at this stage, for any such proposed standard, no matter how well thought out. We've simply reached a stage where (a) all we have is lobbying and (b) no lobbying effort will ever be enough.

see, now that is exactly the reason why this silliness continues. have you considered that 99.99% of the internet is trusting far less scrupulous people than your average small community relay operator? it's easy to say something is impossible if you only look at the worst case scenario, and make excuses why it's not ok to deliver something that works and is secure enough. nostr doesn't even need widely used DMs for all kinds of scams that actually make money for the scum who run them, already, why exclude a use case based on this when it's no different for the public side?

"it can't be done" is a red flag for an inventor, which you are not. all i'm hearing from you is "this other bunch of people said this and i'm too stupid to think any more about it because they save me from the pain". pathetic.

Here's what I'm assuming is the end-game you're picturing. -All clients converge on this one DM standard over time -Other standards effectively get weeded out, not to be seen again -When someone on nostr says "send me a DM" it's always gets sent this one way, and this one way always works. Or are you picturing there always being competing and non-interoperable DM standards? A sort of ice cream buffet, choose what you like?

What are you talking about? Nostr had dms very early on, and is incredibly useful for things like a marketplace where customers need to dm merchants. Your being a technocrat

I am so pleased to read this from one of the original designers of the protocol.

I'm coming at this from the angle that nostr doesn't have to be an everything app, and indeed the more it tries to be one the more it loses itself.

Just make a simple client, if that's what you want, but I cant see how limiting protocol makes sense.

It depends what you see a social protocol as. Before nostr we had signed json events on websocket relays. Then we had nostr. And now we are more or less back to signed json events on websocket relays. For me a social protocol is a set of guarantees. Not perfect guarantees, mind you, but still, strong ones. A guarantee that if you add a relay it'll work, just as any other relay. That if you write a note it'll get shown just the way you wrote it. The vision for nostr, as I understand it, was a very limited number of quite strong guarantees. But now we're back to a space with so few guarantees that we can more or less say we have no guarantees. When people talk about nostr now, they're often actually talking about signed json events on websocket relays, the thing we had before nostr. Relays are not guaranteed to work, for whatever thing you're trying to do. DMs are not guarantees to be sent to who you send them to. Media are not guaranteed to load. Sing-in methods are not guaranteed to be supported. The list of guarantee-less and guarantee eroded things goes on. Does this mean signed json events on websocket relays are bad? No, they work great as an alternative to APIs, and much of the tooling for this that's come out here is great. But it's gone from being a social protocol that your average social human being can wrap their head around to being a sort of devkit for json events on websocket relays, and my take is that this is a bummer. Making a client for more constrained things doesn't work. Any client would suffer from the current lack of guarantees. We're at the point where if a dev wants those guarantees back then at the very least a soft fork is needed.

I think it's a million times better. Both are somewhat centralizing, but this is really easy to use and to provide, and much faster. And given that they're both centralizing this one at least gives us DNS domain names as reputation mechanisms, which are ok to be used in the short term.