Oddbean

Interesting, I was always under the impression it was but I'm in no position to understand/argue it. Can you explain why it isn't and what is a better description for it? I think it's important to be precise with language especially in technical applications.

I want thinking the same thing as you. I thought nostr didn't really fit in the definition of decentralized, federated, mesh, p2p, any of that. But as I was replying to you in support, I realized that if I try to define what decentralization means, why nostr does not fit and try to give an example, I can't. Because it is decentralized

Nah, the definition is very simple: can Nostr recover functionality after relays fail without human intervention? Definitely not. Decentralized systems don't depend on any specific resources to function. When resources fail, additional ones can be brought up to replace them without human intervention by users (beyond of course, the people choosing to run new nodes).

If anyone could be a relay in a useful way, without permission. Anyone can be a relay without permission. But no-one else will use their relay without in a useful way. Thus relays are centralized. To fix this, among other things, nostr needs to find a decentralized spam control mechanism. This _can't_ be based directly on Lightning, as Lightning can't directly prove a sacrifice of funds because it can't prove that a payment actually happened. You could use lightning for an indirect proof of sacrifice though, eg aggregating multiple parties in a merkle sum tree under a BTC proof of sacrifice.

Nope. You are using that term totally wrong in this context. A federated system is a system like email, where individual users use the system though a centralized entity of their choosing. Nostr is closer to that model, due to how relays work. You choose the relays you use, and other users also choosing to use those relays can communicate with you. But it's not a very good federated system, as that aspect isn't made clear. So a lot of functionality is in practice centralized, as it only really works if everyone uses an overlapping set of relays.

Mmmm... no, it's not the same. I can send an email from different SMTP servers, but messages not coming from the "right" SMTP are nowadays mostly discarded. And even during the times when that used to worked the recipient couldn't verify its authenticity. And even if that really worked today then I won't be able to receive replies unless I submit myself to centralization (single point of failure, the postmaster.) See? You don't understand how it works.

The majority of clients now (although not the ones with most users) are using the "outbox model" (also misleadingly known as "gossip model") which mean they will connect to any rogue relays they think they can find notes from -- so if I'm publishing to wss://pyramid.fiatjaf.com/ and you follow me then your client will connect to that even if that is not in your "relay list" (even the idea of a static "relay list" is an antipattern in my view). This means anyone can actually run a relay and that relay will be useful and used. How to find out which relays each person is publishing to is the hardest part and not straightforward, but in practice using NIP-65, NIP-05 relay lists and relay hints in events works well enough, and there are many client libraries that do it automatically. You can reverse this pattern for other use cases, like mentioning people and replying to their posts in a way that they will see your stuff even if they don't follow you (NIP-65 specifies this) and do other variations for other use cases.

Incidentally that also solves the spam problem: for following people you don't have to worry as you'll only fetch stuff from people you follow. For spam on "global" timelines and in reply to other people's posts, you can easily limit your read to relays of a certain kind that provide some form of anti-spam control, and each relay can implement different techniques, some may use Lightning, others may use closed whitelists, others AI-filtering and so on.

Nostr clients that utilize indexers for content display - like Primal - are even better at surfacing content from “long tail” relays. Anyone can run a low-powered obscure relay. As long as the relay is included in the NIP-65 or NIP-05 relay list of a single nostr user, that relay will be indexed. You can totally run a relay on a raspberry pi and have your content accessible by millions of users. Now, an argument can be made that this model introduces centralization at the indexer level, which is true. The good news is that anyone can run an indexer, and we are already seeing many indexers being stood up. I envision hundreds of indexing services with all kinds of configurations in terms of relay lists, event types and date-based pruning. The most encouraging part is that these different decentralization techniques are sprouting organically by people acting in their own self interest and without any central coordination. The core nostr protocol is solid and makes it easy to build these types of solutions. Therefore nostr decentralization is much better than it looks at a first glance. @pkt @niftynei

The spam comment is nonsense and solved at the edges, no need for any lightning shenanigans. The relay stuff you point to is already addressed by the outbox model, some clients just don’t implement it yet, but where it is it works great and removes the concept of “second-class” relays.

YYYYYYYYYEEEEEEEEEEEEESSSSSSSSSSSSSSSSSSSSS it does it does it does it does omfg it fkn does X.X 127.0.0.1 is home. ::1is cancer e.e nostr:note1gd7kalkjf6wsqwehhtzzj4lweukf052dt25ru8af3xrf4yjl2r0snxxqnl

Clearnet IPv6 is a whole lot simpler than IP4 IMO. Right off the bat, there is no NAT nonsense. The only annoyance I've had is that too many devices (like network enabled printers) only support /64 subnets. The IPv6 mesh is even simpler. The only thing you might configure are some remote peers (LAN peers are automatic).

Big Tech will never fully support IPv6 - IPv4 forces consumers to use centralized services. I recommend IPv6 mesh VPNs like Cjdns, Yggdrasil, Pinecone. Every device gets a permanent cryptographically authenticated IPv6 that is also mobile. A SIP client can use the raw IP in the contact list - no need for telco, DNS, or TLS. Where IPv6 is supported, the mobile IPv6 protocol (easily self hosted) lets an IPv6 on your net be anywhere that support clearnet (normie) IPv6.

Interesting. I was always under the impression it was the other way around. That linking a public IP directly to a device was potentially a privacy problem and that it was more private to access the Internet through a NAT.

For clearnet IPv6, that could be an issue. But just as with IPv4 - use a VPN if you want to obscure your IP. The Linux IP6 stack will listen on a stable IP, but make outgoing connections on a random one that changes periodically. So at least that obscures which machine on the LAN is making to connection.

How about decentralized relay discovery algorithms? We can use what is already used in torrent. For example, "relay exchange". Just modify the clients to automatically subscribe to relays of followed users.

nostr is just a messaging API the definition of it is partially centralized and some of the participants have been extremely unilateral in many decisions on that repository the actual implementations are extremely variable, in part because the specification is vague in many places what makes it decentralized is that ultimately there is no such thing as an "official" compliant API implementation and clients don't get restricted to one set of "official" relays to request events from and publish to

you're right, it's interesting when you look at nostr this way. nips are supposed to be standards but it's basically just chaos. the only thing that's universally implemented is nip-01 and maybe nip-02 and yet, it's working somehow. kinda like the internet itself. incredible that any of it works at all.

SMTP is also a centralized protocol, and it has nothing to do with official implementations or servers. The centralization pressure is baked into its design. The same is true for nostr unfortunately.

Like this? nostr:nevent1qqsq5zzu9ezhgq6es36jgg94wxsa2xh55p4tfa56yklsvjemsw7vj3cpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qy8hwumn8ghj7mn0wd68ytnddaksz9nhwden5te0wfjkccte9ehx7um5wghxyctwvsq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qgsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nq0ssmgc