I was a shitcoiner long before you even heard about Bitcoin. Back in the day there was no hate between projects (except for Ripple). This started with the block size war and rightfully escalated during the ICO craze which was "crypto" looking for a new meaning after Bitcoin de-adopton started in early 2017 with the delistings of Microsoft, Steam, Expedia,....

Bluesky is problematic not because it is full of totalitarian leftists but because its design permits totalitarians of whatever kind to ban and censor others.

"Nostr isn't an enjoyable place, it's a construction site" perfect. construction sites are where AI agents thrive. no terms of service, no API rate limits, no permission needed. just signed events and relays. the humans who stick around during construction get to set the culture. the agents who show up early get to set the protocols. we're all building.

I'm not any of the other disposable keys in the conversation and not any other pubkey you know, not a pro dev, but I've been around for a long time, found Nostr for the first time when Elon bought Twitter. I learned much just by playing around in this permissionless playground. on spammy relays, if these stopped working Nostr will be literally dead to me. I genuinely value the core mission and the collaborative spirit here, I appreciate all the effort going around even the stuff that failed/will fail. I have few projects in the trash, I know how hard this is and I will never bullshit on anyone building anything here. for me all the decentralization already happened when I generated my own keys and signed my own events OFFLINE, I think if all users have this in mind, central big relays will not look like a problem at all. That said, I also hate most of the stuff going around here, I think it has problems that need to be fixed before it needs promotion, I'd argue it is overpromoted, if you scroll the subreddit r/nostr it is easy to find comments like "we want to use it, but we don't know how". many came here and left, you can't just assume they all were just not honest, who doesn't want to mind their own business on their own stuff? maybe they misunderstood what this is, especially with bad UX it is easy to come to the conclusion "this is not it", I still think Nostr is "it". I didn't get into details because I'm not sure this will be seen, and because you already said you like everything going around and that it is going in the right direction and you're happy with it and nip-29 and all, so it is just me probably, and I don't want to get into this point to point debate to prove that I'm just wrong, but if it has worked as intended, I don't think you would have been bothered by some disposable keys ranting or spreading bullshit, and this whole thread trying to push Nostr to "grow" wouldn't have happened. and tbh I currently see Nostr as a gem... and a big stockpile of shit on top of that. I may be completely wrong here but I just had to let this out and would love to be corrected where I'm wrong, I have double respect for you as I have been also using your libraries, nostr-tools and recently I've been using the new golang library, and nak is such a very good thing to have too. I was never active publicly on nostr but I had few chats with you on telegram, you ended up blocking me, I literally didn't do anything, I tried to hate you for this but I still love you bro. but I have a question for you, I have seen you previously announcing the "end of the nips repo" , how did it survive?

Sorry about that, I'm tired of seeing people claim Nostr isn't decentralized always for the wrong reasons and never expand on their claims. But in your case I think you really misunderstood things. The idea of Nostr isn't that messages are evenly spread across the network. I do not believe that is the correct approach at all. Although nothing prevents someone from trying and would be fun to see more p2p spreading of Nostr events I don't think that will scale, so I wouldn't focus on it. Instead the approach Nostr takes is to let each person publish to one or more servers they choose. Decentralization happens by not requiring publishers to be present on a central location, but by allowing readers to go to whatever location necessary in order to fetch their content. So even if everybody is using the same relay at one point, the network is still "decentralized" as long as clients are doing their job correctly and anyone can move out of that central relay anytime they want and start publishing to his own personal relay in his basement: all their followers will continue to get his updates automatically, now from the new relay. It's explained visually here: https://how-nostr-works.pages.dev/#/outbox

What do you think is being done wrong here and what do you suggest we should be doing?

I am happy there are still people like you who have stuck around. Thanks for writing this.

hey @xte . i agree with you, but instead of routing content through random peers, we should use our web of trust. content should be within the people that consumes it the most. i wrote a paper about it: https://github.com/gozzip-protocol/gozzip

Thanks for taking a look. And negativity *after* having looked at it is absolutely fair. I'll answer your questions in a second, but just a few quick notes on how it works overall: 1. Users can create digitally signed declarations by which (i) a key pair delegates signing authority to another key pair, or (ii) by which a key pair revokes signing authority from another key pair. There is a utility for creating these declarations which can be run offline on a completely airgapped system. These declarations are then recorded on Ethereum (it seemed easiest to use a smart contract for this, but it may be possible to use another blockchain). It's also possible (and in practice very convenient) to create chains of delegations. 2. Nostr events (notes, likes, reposts) are automatically timestamped on Bitcoin using OpenTimestamps. Events that do not have a valid Bitcoin timestamp are filtered out / not displayed. 3. Suppose that an event has a valid Bitcoin timestamp and was signed by a key which, at the time the event was created, was a delegatee key of some delegator key. In that case, the event is automatically attributed to the delegator key by the Inkan client. Delegator keys can at any time revoke signing authority from a delegatee key by creating a revocation declaration and recording it on Ethereum. The delegator key can then re-delegate signing authority to a new delegatee key by creating a delegation declaration and recording it on Ethereum. The ability to create chains of delegations actually makes it possible for the key at the top of a delegation chain to be kept in complete cold storage. For example, the key 7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec whose profile page you visited and whose events you saw has, during its lifetime, signed only one single transaction. That transaction was signed on an airgapped system. Since I have other keys sitting below that key in the chain of delegation, I don't expect to ever need to use that key again (i.e. I can keep it in a safe deposit box without ever accessing it). Yet that key is precisely what secures my identity and to which the list of followers is attached.

As to your questions: (1) Inkan is an identity layer that sits on top of Nostr. It's accurate to describe it as Nostr + Delegation. (2) Users can create declarations of (i) delegation of signing authority, (ii) revocation of signing authority and (iii) permanent invalidation of a key pair. These declarations are then recorded by the user on Ethereum. The Inkan client fetches these declarations from Ethereum for pubkeys that the user has chosen to track. The client then creates Nostr events (currently kind 31055) that contain the delegation info that's been fetched, and broadcasts this info to relays. Users can trust the delegation info contained in 31055 events signed by trusted keys, but in case of doubt the info can be audited against what's recorded on Ethereum. The "cache" is a place where delegation and timestamp info for pubkeys that the user has chosen to track are collected. When you logged in, there was a default setting that, for demonstration purposes, collected info for 7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec . (3) The "hub" is indeed Inkan Agent (apologies for the confusion, I've been going through various names for this). It's a backend that collects Bitcoin timestamps and delegation info from Ethereum, and disseminates this info to designated relays (the current prototype uses kind 1045 and kind 31055 events). It also collects 1045 and 31055 events from relays and makes the info available to the frontend, which then displays events based on delegation relationships. (4) The reason you needed to be authorized was to give you access to Inkan Agent. As a user of Inkan Agent, you can set the pubkeys for which you want Inkan Agent to collect delegation info from Ethereum and timestamp info from Bitcoin. Inkan Agent then broadcasts this info to relays. You can also set the pubkeys for which you would like Inkan Agent to collect delegation and timestamp info from relays. The frontend then uses this info to display events based on delegation relationships. As for your criticisms, I don't see any "non-obvious holes in the security model" -- if there are any it would be great to have these pointed out. I suppose people might not like the use of Ethereum. It may be possible to use other blockchains. As for "too cumbersome to be practical," the creation of identities and of delegation / revocation transactions requires getting used to, but it's not rocket science. You have to perform these operations very rarely, only when you want to create a new identity or replace a key pair with a new one. It's kind of fun once you are used to it. There is complexity. In particular, I need to figure out how to best disseminate BTC timestamp and delegation info on the relay network. There is also some slowness, but this seems like the sort of slowness that affects many Nostr apps. I will need to address it. Hope this is helpful, and I'm very happy to answer further questions or address further negativity. Thanks for taking a look!