GM!

I've heard people mention this before. In which clients did you have this problem?

Another area of confusion for people is "nostr address".

This was difficult for testers to grasp because they didn't even know what "nostr" means.

This is understandable given the naming difference of clients and protocol.

One solution that I can think of is to rename it to "Unique ID".

It's a more clear term and eliminates the need of having to understand what nostr is right away. They can still discover the protocol over time without this up front confusion.

Here is an example of how I would describe Unique ID input field in client settings:

"Usernames are not unique in Snort. A unique ID is a human-readable address that is unique to you only. This helps friends identify the real you."

Notice I did not use the term nostr, but referred to Snort directly because this is the client that person is using.

To lessen the hand-holding, we can add some additional copy "Why are display names not unique?" with a link to learn more about this concept - and use that to introduce the protocol.

Another solution might be to tuck this field into an advanced settings dropdown. NIP5 DNS-based IDs are not a good solution for majority of people and only come in handy for higher social presence individuals. They can find this field because it'll be more important to them. As for the rest of us, the burden of proof can be through other types of verification as we've all been doing already such as posting on another platform.

Curious to hear your thoughts!

All relay have policy and can delete your note if they want.

right now they arent a lot of relay and there are central point. So we need all to have private relays with not central authority.

right now nostr is control by few people. And if u hit those nerves on people, u are out.

Yes, but in Lume v3, you will have a option to keep Lume running in background like discord or slack, the cons is it will cost a bit of memory

Currently, because some of limitations, I cannot separate UI and backend service, maybe it can be done in v4

GM. My dream when start building Lume is it can use as a Nostr Relay, and today I near achieve it, this feature is almost ready, I will show it to you guys in the next week 🔥

Tailwind and Typescript have probably been my 2 biggest productivity boosts of my (albiet relatively short) career in software.

I don’t know why more devs don’t use Tailwind 🤷‍♂️. It looks decent from the start so you don’t have to worry about the basics.

Exactly what I’m thinking

I'm considering adding a "relay-set router" to NDK.

This would give developers the ability of providing certain policies to route both event fetching and publishing to a particular set of relays, overriding the default calculation. It could (or not) include in the information the router receives the selection that NDK has done, including what it wants to do per the outbox model.

I want to use it for an application that I'm making that creates certain kind of special events and with this I could create a router that says:

"whenever you fetch/publish kind XXX, send it to only these relays"

"whenever you fetch/publish kind 0, include PurplePages, otherwise don't include PurplePages"

Does anybody find this interesting or useful?

Ugh, nostr UX is still in shambles.

To create a prism you have to know what a listr is. To create a listr you have to know what kinds mean. To ask the creator you have to search for their name, which you cannot find in search depending on the client you use.

We need like a 2 week summit to just sit down and talk this shit out or something and everyone test everything. Use it fully and make note of what's confusing.

I can't be the only idiot who can't figure this out.

Still a few rough edges but I would dare to say that Asahi Fedora Gnome on M1 is one of the best setups I've experienced.

Blazing fast, good graphics/rendering, superb battery life, and a great open source OS