Thread - Nostr Hypermedia

I made a relay that charged for access and started working on a framework for making custom relays with arbitrary policies in early 2022:

GitHub

GitHub - fiatjaf/expensive-relay: a nostr relay that requires a single registration payment per pubkey

a nostr relay that requires a single registration payment per pubkey - 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: View article →. 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?

View quoted note →

↑ Parent

Replies (3)

Viktor 1 week 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 1 week ago

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.

1 replies ↓

JOE2o 1 week 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.

1 replies ↓