Nostr Web Client

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?

JOE2o 3w ago

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.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 3w 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".