I was able to log in to the web client using the invitation code you provided, but the backup failed and I couldn't set up the pubkey ring properly, which resulted in me being unable to log in anymore. Could you please send me a new invitation code once again?
Primal solved this problem by building a proxy "relay" that handles fetching, aggregating and caching and it's by far the most used client since the competition sucks. Some kind 1 clients don't even try to do any fancy client-side caching and default to download the whole internet every time you open the app, ffs.
#Pubky seems to have a similar design to Primal with homeservers and indexers: I and the people I follow can host the data wherever we want (homeservers can be resolved by pubkey via pkarr/pkdns) and an indexer can easily find it, aggregate it and push notifications to clients. One downside of this design is that it requires trusting the homeserver since the data is not signed. On the other hand, the UX is way better if you don't have to sign everything you poast.
You might not like nostr:npub13ndpm2hm9hud4azsq5euhf5mv3d05r90wymwxsd7rdn29609hhvqp60svh's style but the design choices of #Pubky make sense and the https://pubky.app is really good, I recommend you check it out.
Discussion
hey N, i can't create invite codes sorry. you'll have to ask John.
okay!🤙ありがとう
I have a spec ready for #communikeys that lets holders of a Community-badge (confirmed by the communikey) hand out that same Badge to others. Those invited profiles, however, cannot hand out that Badge, until the communikey confirms the Badge for them.
I think an invite tree that only has one layer like that is the best middle way for good UX and feasibility on the App, Relay and Spec level.
https://wikistr.com/nip-badge*a9434ee165ed01b286becfc2771ef1705d3537d051b387288898cc00d5c885be
nostr:npub1h49w8en79xty6j2pwgnpm3znjhyf767jua6xgt3kvyn3w80ms86s2z9kay how easy would something like this be to implement on the (automated) relay side?
The idea is that you'd (for example) ONLY accept Articles from the profiles that have a "Member" Badge (awarded by the #communikey itself OR someone with one awarded by the #communikey, not deeper).
If I understand the spec correctly, it shouldn't be that much hard. In a general big relay that is used by different clients, this check may break the function or performance of the relay. But in a Communikey specific relay it won't have any issues.
I'm setting up the spec so I can do in-app verification and still have it work in nostr:npub18stt78efprta2el02tzgnez6ehghzgtt000v58967wvkgezjmprs0n7h7u for #communikeys that use general dumb relays.
It'll just be slower and (potentially) a bit spammier.
Nice, will read it once you published it.
It's coming together in these wikis:
Thanks a lot. I'll read it. 👀
Great! Good to know 😃