True. Filter.Nostr.wine does this with the broadcast feature. In addition, some relays aggregate from others so there’s no real telling where your event will end up if you send it to a publicly accessible relay.

I felt like pizza last night, so I found a dough recipe in the family cookbook, raided the pantry for toppings and made three.

Having collected some feedback, combined with some personal ideas, here are what seem to be the areas for most improvement in Nostr / clients:

Discovery is an issue, people don’t know who to follow. Since the are not that many diverse profiles that are easy to discover, it might be easier to recommend topics (hashtags).

We could also add profile descriptions on other clients (I think Damus already has this).

Spammy global is a turn off.

Could be solved by recommending Hash tags to follow. What if we create a list of common hash tags (kind of like subreddits) and show those to people? To help populate them, we could (if technically possible) create a client-side list that can be autosuggested as you type in a hashtag. For example, if I typed #p - it could suggest Photography, Plants, Parenting, Philosophy, Programming, etc… This way people who are using hashtags to tag would have an easier time picking something that already exists instead of making totally random ones that nobody is going to discover unless they see it in a note.

Grownostr (IMO) is not a useful hashtag as it is too generic and mixes too many subjects into one. If it were up to me, I’d ditch this one and use auto-recommended ones if/when implemente.d

Crypto talk is a turn off. Can’t stop people from talking about what they are passionate about, so I think the best strategy is to find topics to follow.

Global could become a list of topics you follow instead of actual global notes. Once you follow a few topics, it would become much more useful.

Some (nobody?) understands NIP5 without reading into it. Personally I think this is a terrible name to begin with. Either rename it, or get rid of verification entirely. Since impersonation is likely to affect a smaller number of accounts, we could add paid verification for people who only exceed a certain number of followers. Not sure how you’d enforce this across clients though.. ideas welcome.

People are very confused about keys. nsec, npub, what to enter into a website, what not to… totally understandable. I propose we add small explainers and use old terminology within labels to help people understand these concepts. For example, an input field could be Username (npub) Password (nsec). Of course, I can already hear people shouting at me “But this is not what they are!” Rightfully so. Perhaps, then have tiny explainers, visual, video or just text to plainly explain the concepts right within signup.

Relays - hard to understand. No onboarding process talks about relays now. Idea I have here is to automatically connect people to top X relays while showing this screen in onboarding AND giving a quick explanation of what’s a really. Use fun, engaging copywriting combined with an image or a video to increase the odds of people reading / watching it.

People have a very hard time in profile setup. I think Damus is leading the way on this. Personally, I would stop immediately all development of other features and focus 100% on profile UX. This is a critical step IMO and needs to be absolutely nailed. We can’t expect people to use 3rd party image services to add a profile picture. It needs to be as easy as every other social platform.

People don’t know what zaps are, or how to find a wallet. Steep learning curve. Ideas here: Add old school terminology along side in labels. For example: Zaps (payments). 

For wallets, create a section within the client that explains wallets and recommends a few options (are there a few options, perhaps WoW, Alby).

Overall people are not familiar with many of the concepts of Nostr. Solution here would be to create an educational area in a client that covers terminology / concepts and has fun ways to explain what things are. Perhaps even a game or an interactive quiz. I know… a lot of work! 

One idea floated was having no signup process at all and generating a key on Post. I am not sure if this would be a good UX given people might get confused why there’s no way to signup or may not take their key seriously and misplace / ignore it. But, it would be cool to test this idea with some client.

Haha, the ranking is not enabled yet, because it's not yet working. What you see is just a timeline.

You can log in on the main page with extension actually. I already added a bounty for making the like button work :)

I think I forgot to add the author to the view as part, I'll do that, thanks!

Why? :)

I feel like since NIP-05 identifiers verify a user's association with an organization (via domain name control), not their identity, Nostr clients should support a user having multiple NIP-05 identifiers, so that a user can show all of the organizations that they are associated with.

Also, instead of displaying a check mark, the organization should be able to define a graphic/badge/etc that gets displayed for their organization when a user has a valid NIP-05 address for their domain configured. This would more accurately represent the association with the organization rather than the check mark which has historically meant something different (identity verification).

#[0]? #[1]?

AI generated photo of #Bitcoin destroying the US dollar on top of the federal reserve building crumbling. Not bad I’d say! #Nostr #plehby #plebchain #AI

BTW. The websocket thing is something I wonder about often. In a use-case with reasonably frequent updates, is it better to have clients hold an active but mostly idle tcp connection (like websocket), or make them do polling, or some long polling?

A proper async IO runtime can probably handle tons of connections at once anyway. 10k, 100k, maybe 1M.

Also with a gossip-like note fetching, it should be feasible to have lots moderately sized relays, without a loss to usability, so maybe worrying too much about scaling vertically a single relay is unnecessary.

Otherwise some client&application level load balancing might fix the problem. Eg when connecting to a relay it answers with a list of keyspace "shards" (possibly overlapping for redundancy), and then connects/queries to the actually node that holds the data. That would allow reasonably simple and flexible scaling of the relays without complex server side load balancing.