No, it just says that you should know better.

Or maybe you don't want to let other people rebuild your stuff because you do make it as hard as possible.

I want full rebuilds. Absolutely NO dependencies. This BS replies designed to look like more than what they are is exactly why I don't trust anything you touch.

My most charitable feedback - and I will be very happy if this turns out to be the case and I look like an asshole - is that you launched a public beta too early before all the "we mean what we say" items are in place.

I've been in - and leading - businesses like this before and I know how difficult the timing can be, but I've learned from my own mistakes and I think this is important: It's better to launch later than too early, leaving holes for disgruntled pains-in-the-asses like me to exploit. I'm pretty sure I'll regret my behavior later, so apologies in advance... But at the moment I'm pretty jaded and it has resulted in me drawing red lines around these sorts of things that need to be provided on day one, not as "promises for the future":

- Self-hosting as a first-class citizen. Maybe even above the alternative. More "you should self-host, and here's how. but if you simply cannot or don't want to, here's our alternative option" and less "We make it easy for you to not self-host, but if you want to for some reason, here's a link to some docs that may have been hard to find or not yet real".

- Client agnosticism from day one. If there exists only one client, and it comes with defaults that enshrine platform-sponsored indexers, "global" user lists, and other "easy onboarding" features, I'm going to be suspicious that the early choke-hold will ever loosen. I'm not saying this is malicious/intentional, just that network dynamics are what they are and this is how it works. The alternatives are painful and weird, but I believe they're necessary for ecosystem hygiene: attract early developers, incentivize them to build alternative clients; build the first "reference client" but cripple it a little so that it doesn't become dominant too quickly; provide SDKs that make it trivial for developers to build clients (and **foreground this** so that people see it before they see your client)... etc etc. These paths suck for user adoption - but that's kind of the point. User adoption is in conflict with the principles I'm describing.

- Decentralized from the outset. Use an existing social network (Nostr, etc.) to bootstrap users' experience - not your "platform"'s default network. how/why could there be something like "default global users" if a system is actually decentralized? I should start alone in a dark forest - which proves to me there is no central entity. From there let me discover peers in a manner commensurate with my interests and existing social graph: current social network peers who happen to use pubky, "follow suggestions" lists like following.space (ideally curated by not-you), etc. Again, this is bad for user adoption, but see above re: conflict.

That's a bit of a brain dump on what motivated my comments. You're right I could have been nicer and I'm sorry I wasn't. I've been on the receiving end of exactly this kind of feedback and it's frustrating when YOU know what your roadmap is and other people do not and misconstrue it. But because that's how this ecosystem works, its in **your best interest** to be so defensive that people simply cannot get the wrong idea.

---

Of course these are all my deranged opinions and you nor any pubky users need to care. that's the beauty of building your own thing.

The VC funding machine existing may be a bigger threat to Nostr than it not existing.

Pubky seems to use an approach of “homeservers” just like Matrix, the Fediverse, I think ATproto as well…

Keeping a copy of NIP-65 for all users only costs $20/mo at most. There are hundreds of free relays right now funded by absolutely no one. I’m storing all of them at nostr.land for free and I’m not noticing an impact on the cost.

Either way, we can always use DHT if it really becomes such a need.

And the claim that IPv4 or IPv6 is centralized is absurd. There are multiple local registries and not just ICANN, and there have been no cases where someone’s IP block was forcefully taken from them.

"Nostr Finding a way" is useless in this context, we are comparing this ad hoc ideas to the DHT, where reselience doesn't come at the cost of breaking apps. In the case of the federation or purple patches or whatever... you have to hardcover this shit, and if the things you hardcoded go offline then now everyone needs to COORDINATE on what is the new purple pages relay.

This shit is not socially scalable, imagine if a URL only works of both the servet and I agree on the DNS server... it is retarded.

I don't care much about nostr I am discussing a technical aspect... if one compares a hardcoded set of identity relays, and call that equivilant to DHTs, I am going to call them out because that is just retarded... we already have a federation called ICANN and it is way more trust worthy than purple pages or whatever set of relays everyone agrees on.

It doesnt work, it doesn't socially scale and it is just as vulnerable to censorship as ICANN... so no it is not equivilant to DHTs.

I suspect that you are actually missing the note I am responding to, which is a part of the beauty of Nostr i guess 😅

My story will change the value.

They would have stopped it.

When someone writes 350 pages in a couple weeks on things they shouldn't understand, it gets flagged. Guaranteed.

But it's on ipfs and noted on Nostr.

[Checkmate boys]

It’s definitely possible — I and others have built GrapeRank proofs of concept that synthesize follows, mutes and reports into a trust score. Each of these 3 sources of data gets “interpreted” as the first step. Things like replies, reactions, zaps, tags, etc will be straightforward to interpret using the same technique that we’ve already used.

Have you done a deep dive yet into #PageRank? PageRank and GrapeRank are both examples of centrality algorithms. PR is easier to explain, easier to implement and historically significant as the thing that launched Google in1998 and wiped away — like magic!! — the vast majority of spam from internet keyword search. I’m excited to see PR and similar algos in production & in use by nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz9mhxue69uhkummnw3ezumrpdejz76jympz, nostr:nprofile1qqs0dqlgwq6l0t20gnstnr8mm9fhu9j9t2fv6wxwl3xtx8dh24l4auspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg4waehxw309ash2arg9ehx7um5wgcjucm0d52m9qj9 and others, and I would like to see more nostr devs understand and appreciate what PR and other centrality algos can do for nostr.

I’d love to see one or more nostr clients implement tags. Probably worth looking at how Pubky does it from a UX perspective.

No, we don't need a relay for every thing (and every combination of two or more things), just like we don't have a website today with a community for every thing, but we have some because someone did them and they succeeded, while others were never tried and others failed, and we're still ok.

I think having Nostr and the universal relay as a standard makes it much easier for more of these niche relays to exist, so we'll end up with a lot more stuff.

Again, I'm not saying the WoT approach shouldn't exist, it definitely should, and both approaches can be combined. I'm just saying we shouldn't decide on that being the only solution, because it's quite complicated and we can't be sure it will scale across the vast spaces of humanity and relationships (and computer resources for downloading and processing all the data).