So on the spec level there is a group of keys that are authorized to the conversation and on the app level some of the keys are the same person and need to be displayed that way?
Inheritance for Nostr event kinds is an interesting idea! What approach did you have in mind for this?
Simply creating a new Kind B that “claims” to inherit from Kind A doesn't work, as Kind A clients wouldn't recognize Kind B events by default. This isn't real inheritance.
I guess a true inheritance could be achieved by using Kind A with a special tag (e.g., [w, "application article"]) to indicate a subkind. This creates an inheritance framework for kinds.
- Kind A clients could render all Kind A events, ignoring subkind-specific properties
- Subkind-specific clients focus on their relevant events
If we want to go one level deeper, we could simply extend the tag (e.g. [w, subkind, sub-subkind]). However, I’m not sure if that would ever be necessary.
This method is backward compatible and pretty straightforward imo.
Would it work for your use case?
If Nostr succeeds, relays will need viable financial models (e.g., user fees or data monetization). As profitable businesses, relays would then be incentivized to maximize, not limit, note volume. IMO
Let’s say the whole world goes nostr. There are billions of active npubs. I want to find the outbox/inbox relays of someone. How does nostr go about this?
I cannot query all the possible 10002-kind relays (partly because it’s inefficient but mainly because I just don’t know them all).
DHT over pubkeys ? Are there other solutions?
I guess the way to go about those things in the global sense is building in layers. Nostr libraries for logic and ui are a good direction in that sense. The hard problem is creating “correct” layers, preventing leaky abstraction.
Yes.
Add a d-tag with a uuid. That uuid corresponds to the subject of the document.
Then create a new private key to sign the event.
Anyone you share the private key with can continue editing the document by creating new event with the same uuid and same key.
Everyone else can “fork” the document. They do it by creating a new event and using the same uuid in the d tag.
People don’t have to use the same uuid when creating a new document on the same topic. But they have incentive to do so. If your document about Blue Whales already got traction, I would want to use the same uuid to suggest my document as an alternative document for the same topic.
When creating a new version, one can also add his personal pubkey in a p-tag so people know who created this version.
https://gluegroups.com/blog/introducing-glue-work-chat-for-the-ai-era
This is very interesting.
TLDR: slack competitor which set threads as the atomic unit instead of channels, similar to ChatGPT.
Maybe we can bring it to nostr once we get other chat features more figured out. Public conversations are already mostly thread-based (twitter conversation model). Private chats (two people or a multiple people) which are thread-based is interesting path to pursue.
@fiatjaf@hodlbod@PABLOF7z@JeffGhttps://m.primal.net/IHrD.jpg
The confident manner in which you tell everyone how they should build on Nostr, moments after calling it stupid, while constantly noting the genius of your unused products at Synonym, makes it all just feel quite ridiculous.
Oddbean new post about login | logout
Notes by Vincent | export