andros

I completely agree. It's minimalist, with no modals within modals or hidden buttons (except for the obvious context buttons). Whether you like the UI design or not is another matter.

Once you learn your workflows, it becomes quite natural. But I agree that as an entry point it's confusing and feels clunky.

Thanks for the action! Perhaps my comments make me seem anti-Nostr, but if anyone reads my articles, they'll find several where I praise some of its design ideas and even implement them from scratch as an exercise in understanding. Therefore, I can venture to say that it has some scalability issues inherent to its architecture, but not due to poor design. It seeks a design somewhere between total decentralization (like P2P) and federation (like ActivityPub/Mastodon), with its advantages and disadvantages. It's not perfect, nor are any of the other solutions. Perhaps the NIP-77 extension mitigates some of the replication, but architecturally, it can't avoid it.

Is it suitable for small communities? I don't think so; it's over-engineering. A small decentralized or federated system is sufficient; successful examples like Tilde or FriendCamp reinforce my point. But everyone has their own perspective; I prefer simple systems without third-party dependencies. Small and sufficient is better than large and complete.

Is it better to have something small with a certain level of usage, or a network of millions of users where only a negligible percentage actually interact?

Sure, it's Wei & Tyson, "An Empirical Analysis of the Nostr Social Network": https://arxiv.org/abs/2402.05709 The 98.2% is download traffic, not relay-to-relay sync. Across 17.8M posts and 712 relays (second half of 2023), the average post sat on 34.6 relays, and since clients subscribe to every relay in their list, they pull the same event over and over.

On curation, expiry and registered identities: I agree, and that's more or less my point in the article. A relay that only accepts its members and drops old content is a small community with a gatekeeper and someone paying the bill. That's fine, it's what I'm arguing for. But "the content survives when a node drops" comes precisely from the replication that costs money. The more relays curate and expire, the more survival depends on someone (often just your own client) keeping a copy to republish.

I also wonder: if each administrator has their own rules and configurations for their respective relay, is it a decentralized or a federated network?

I wrote about where each protocol puts its single point of failure (identity, discovery, cost) here: https://en.andros.dev/blog/603e4e90/there-is-no-such-thing-a...

The problem with Nostr lies in its cost and replication; the traffic is redundant (98% of it). The result is a fragile infrastructure; a "ticking time bomb" in terms of costs. Added to this are the typical headaches associated with any decentralized network (spam, moderation without a central authority, Sybil attacks, a constantly growing volume of data, etc.). Furthermore, it is dependent on relays (which is not the case for other networks).

What is your goal? To talk with other users via private messages, in the style of XMPP or IRC?

This can happen, even in open-source projects. The key is that not everyone has the knowledge or the money to maintain them. These mini-federations make the Internet much richer and more accessible.

And old users!

I added his name to the article and dedicated it to him. Thank you for the suggestion.

I'm doing it myself, it's a stream of my .plan: https://andros.dev/now/

Wow! Thank you!

Great work!

Perhaps a global database or a parallel project like a search engine focused on fingering is needed. The sources are scattered, and clients like yours would greatly benefit from that.

I'd also like to mention that if you have Emacs, I also have my own client: https://git.andros.dev/andros/efinger.el

the bare minimum!

I'm dying! Using Telnet to flirt. The father of Tinder XD

Fantastic! How lovely to read these stories. And what influences Id has had on Finger.

Second place is Cat

Thank you for sharing your experience and story! Amidst the noise, it's rewarding. Good luck with your compositions.

Do you have a bad memory?

What is your name?

I'm very happy to know that I've made you think, and that you've wisely chosen SSE for absolutely all cases. That's what a senior professional often does: limit themselves to one technology.

I'm learning a lot. Technology is full of nuances and details.

I wish! It would have saved so many hours and drafts….

The soap opera continues here: https://en.andros.dev/blog/bd74e61a/were-fighting-over-the-w...

Thank you! :)

It's not necessary. I almost always use iOS.

I would like to invite you to read this article: https://en.andros.dev/blog/ba142044/twtxt-vs-org-social-the-... What do you think?

You're giving me statements and advice without knowing either the hardware I use or the tools. I don't have the resources to do this kind of massive testing; if you're up for doing it yourself, I'd be happy to update the data.

Since you seem so knowledgeable about this, why don't you do it yourself? The code is available in the repository. I'm sure you'll do much better than I can.

50 is the hardware limit, not a personal choice. The code is free and accessible from the article itself. If you can run tests with more, I'd be happy to update the graphs and the conclusion.