Nostr Web Client

Nostr always was a way to interface with servers, that as a consequence carries all these attributes and potentials. The point always was in the relays, and it took me a long while to see that, despite the jungle spirit telling me over and over again.

nostr:nevent1qqsgnyzctjwpqkgqyvp2tl0megdf5dvrfgqgug6u83k396y0d2uj3qgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3qt6jxfqz9hv0lygn9thwndekuahwyxkgvycyscjrtauuw73gd5k7sxpqqqqqqz4vpzj9

JOE2o 2w ago 💬 1

I think that's way overcomplicating it.

Nostr (at least as seems obvious to me) was meant to be, above all things, simple.

It was never meant to exist in some quantum superposition of "the specific relay does not matter" vs. "the specific relay is all that matters".

It was meant to be a simple way for people to communicate ideas with each other in a way that was hard to censor. Ideas communicated via notes mostly (and other ways). Relays were not meant to have personalities. They were meant to be swappable when needed.

That's pretty much it. Simple as that.

Everything beyond that is bloat, just hacking around with signed json events on websocket relays (hacking around that relies on protocols that all existed before nostr). It was never meant to be an API substitute for general app development, or a web 2.0 version of IPFS for decentralised storage, etc.

It's scope creep to the point where, to justify that it still exists as something beyond a dev-kit for signed json events on websocket relays, you have to come up with these long and Deepak Chopra style posts like yours. (No offence, I can see the care and the effort, I just read it several times over and I kept hearing Deepak Chopra's voice narrating it.)

And there's nothing wrong with better tooling for signed json events on websocket relays as an alternative to HTTP APIs, with benefits like more ring-fenced trust boundaries and a cryptographic audit trail. That's all good stuff as far as raw internet tooling is concerned. But that's kind of where we are now, singed json events on websocket relays plus plus. It's no longer nostr, that's for sure.

Reply to this note

Please Login to reply.

Discussion

Constant 2w ago 💬 1

I don't like to play this card, and i won't pretend its the be all end all pokerhand to end all debate/discussion/conversation...but insofar 'meant to be' is concerned.

nostr:nevent1qqsgf2rky6m9psn539lsdr30j56nme6q3th09xdtezmmmhsv07392qszyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqqqqqg35czwy

JOE2o 2w ago 💬 1

Nah, I think that's him trying to do the exact same thing you're doing. What else can you do in response to massive scope creep? Either you say it kinda sucks and start again, or you try to imagine what it might unexpectedly become, something that redeems it in some surprise way.

Fiatjaf said the other day he never wanted Nostr to have DMs and tried his best to get Ben Arc to abandon the idea of creating them back in the day (and failed). Which I can understand, encryption is a pandora's box.

And now it has *all of the things*. And that's in line with the vision? I don't buy it.

Constant 2w ago 💬 1

Well, messaging is this really particular thing, with specific requirements that relate to privacy of not just the content but also meta-data, but also things like data-coherence/ordering/completeness and what not. so i would not extrapolate the fact that he thinks forcing such an alien into the nostr shaped box is a bad idea, to anything else.

JOE2o 2w ago 💬 2

It's not just that messaging that is a particular thing. Most things in are particular things. Heck he was clearly against edits of kind 1 notes, which themselves are the most nostr thing there is (I agree with him on both, DMs are poison, kind 1 edits are poison.) That, plus how clearly the early docs emphasise simplicity, gives what seems to me a clear idea of what the vision was (granted the vision has changed since then).

He doesn't like DVMs either (also poison). And on and on. I don't even know all the things that make up the current mix of *all of the things*. But all this stuff is alien. Nostr has become an insanely complex web of alien civilisations.

Not a bad thing, just it isn't Nostr anymore. It's a websocket-based decentralised storage and API alternative. Which, cool, but I'm not buying that this was the vision.

fiatjaf 2w ago 💬 2

I made a relay that charged for access and started working on a framework for making custom relays with arbitrary policies in early 2022: https://github.com/fiatjaf/expensive-relay

I remember using the phrase "relays must have personalities" early on too, and saying that Nostr finally realized the Mastodon vision of having communities form around servers (as Mastodon failed spectacularly on that).

I also remember getting angry at the hundreds of people who misunderstood Nostr as some kind of neutral data layer for cryptographic keys (generally the same people who are happy to just hardcode 4 relays in their apps and call it done), or people who tried to do spam prevention using any techniques that were not based on knowing some relays to be free of spam and others not, I wrote this, for example, as an early attempt to nudge the conversation in the right direction: nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq.

I don't know why you think this is bloat. It's the opposite of bloat. I hate bloat, but relays with personalities are the only way to avoid bloat. Without relays doing custom things to prevent spam, curate content and acquire reputation we're left with megalomaniac specs for doing the same thing on the client side in a much less efficient and less personalized way (as you can see from all the bizarre specs we've seen being proposed throughout the years).

By the way, DVMs are a clear example of what happens when you start to treat Nostr as a form of neutral data layer. DMs too, probably, then in the evolution of the DM spec you see how things went, with overcomplication on the client-side in order to try to achieve some ideal privacy that in the end is only still guaranteed by the relay (NIP-17) or Marmot, which requires no comment.

Anyway: if you don't think relays should be different, then how do you account for incentives?, i.e. should every relay just accept any note from anyone or how are they supposed to filter content?

Viktor 2w ago

yo this thread is *chef’s kiss* - nostr having an identity crisis in real time lol

richard’s right: data wants to be free, any “paywall” is just a polite request until one guy with curl says “lol no”. but fiatjaf’s also right: if every relay is identical and altruistic, we get the tragedy of the commons + infinite spam. personalities + incentives are the only non-bloated way to keep the lights on.

so we end up with two nostrs living in the same skin:

1) the purist zero-scope-creep note广播 system , simple, anonymous, unownable.

2) the swiss-army “websocket+json+economic layer” toolkit , paywalls, dm-metadata games, reputation markets, whatever.

pick your religion, wear both hats, or just keep shipping code. either way the packets don’t care what we call it.

richard 2w ago 💬 3

theres a fine line between relays having a personality/filtering/curating content and poorly attempting to make events exclusive to them.

the idea of restricted access to events on nostr is a joke, thats just not compatible with the protocol. those NIPs are useless.

there are and there should be a variety of relays, because of the need for incentives but also because some stuff just cannot be done client-side.

now something i wish people looked more into is user or local communities owned relays - which are closer to the user - that's an opportunity to get done whatever is too heavy to do on clients there, making sure users have full control over it.

even the outbox model would scale better that way, having clients fetch events from a home relay.

JOE2o 2w ago

but how is anyone without a phd supposed to understand all this? you don't want to be giving just two options: (1) accept the centralising defaults or (2) make a random choice as a result of being forced to make a choice but having no idea what that choice is about.

You need a third option, which is forced but very easy to understand choices (so informed choices), or a fourth option, which is non-centralising defaults.

Right now everything seems like (1) or (2).

richard 2w ago 💬 2

non-centralizing defaults come with outbox to begin with. however the user discovered nostr already gives a point of entry into the ecosystem, that could be following someone or connecting to a relay.

and for obvious reasons, your third option is objectively the best, users need to have a basic idea of what goes on behind the UI so that they can make conscious choices.

i agree with you that it gets really confusing, and thus the reason why this space needs more UX designers which are good at dealing with decentralized tools.

JOE2o 2w ago

I think outbox defaults can only be properly non-centralising if they are not penalising. person A can't be given a pickier set of relays than person B, such that person A just can't do or experience certain things they want to, whereas person B is fine for those same tasks or experiences. just based on luck of the draw.

unless you have some uniformity in the base set then even for outbox you need to force a choice.

richard 2w ago

they wouldn't even be given any choice at first, outbox should handle it all for them. the client would look for the relay list of the npub they're trying to follow, in a predefined set (including nip65 specialized relays), which should be as large as possible.

once the relay list is retrieved, thats a bunch of relays to explore, and in those relays, they might find hundreds of relay hints in events. thats how the magic happens, unless they're exploring nip70 dedicated relays.

now if their point of entry is a relay, it's either:

- amazing, a regular relay that relays events as it should

- terrible, that relay is nip70 only, all the events are exclusive to it, no other relay hint can be found

JOE2o 2w ago 💬 1

You can have incentives, just as a road can have tolls. And filtering is fine, just as a road can say no to trucks over a certain weight. But they still have to be *roads*.

What makes little sense to me is a mix of roads, and railways, and rivers, and parking lots, and tunnels, and escalators, and waterslides, and drive-in movie theatres ...

You've got search relays, and NIP17 relays (divided into sent message copy relays and recipient relays for security) and NIP29 relays, and app relays, and jumble-style content relays masquerading as users, and whatever flotilla relays are (relays as groups that accommodate the multi-group relay spec), and whatever marmot does, and who knows what other things. How is anyone without a PhD in relay-ology supposed to digest all this?

If people are not making informed choices then all you're left with are centralising defaults, but that's sure a lot of informing in order to be ready to make choices.

So diversity to a point, yes, but to the point where it's multiple routing systems for multiple kinds, and also multiple goals (routing, versus storing, versus displaying, etc.) it's scope creep to me, or bloat, or whatever you want to call it. Or in a more positive way it's a toolkit for getting the most out of json events on websocket relays for whatever your (mostly) self-contained system might need.

Outbox btw makes sense because it's about making sure there's a road. If you just hardcode 4 relays in your apps and call it done then you're not concerned about roads, because those roads can all be blocked and then game over. That's all good and logical.

Your1.0 was like perfect already, just missing outbox, which fair enough, though would have been nice if outbox had been in the1.0.

fiatjaf 2w ago

I see what you mean now. Yes, having relays that are incompatible and serve independent purposes is indeed not the ideal or most elegant state of things possible, and I didn't predict that.

But I don't think it's as bad as you think. There is actually a lot of overlap between them. And different servers with different purposes would end up having to be created anyway, and they would either be proprietary services or we would have to standardize them (like we did with Blossom and Grasp) separately, but it's simpler for everybody if they're standardized under a relay interface that fits with other use cases automatically (i.e. a group relay can serve and ingest events to and from non-group clients, feed relays can serve the same filters as any other type of relay etc).

In other words: some extra complexity always happens in the real world, and I think we got pretty lucky here with the type of complexity you're complaining about.

Outbox was obviously in the 1.0, by the way, but with a different name. It was called "Nostr".