I have been thinking about outbox model since this pod.
I came to the conclusion that outbox model also only works in the context of communities. End-users don't care about servers, community leaders do. Users care about the community they joined. Big difference.
Also, for communities, discoverability matters. Their leaders are ready to pay for services to create a better place for their members.
Outbox model falls apart if it's done on the user-level. Will never work. But it _will_ in the context of communities.
It's a scalable and sustainable model for nostr.
Login to reply
Replies (2)
you are describing the Communikeys proposal
https://wikistr.com/nip-communikey*a9434ee165ed01b286becfc2771ef1705d3537d051b387288898cc00d5c885be
https://github.com/nostr-protocol/nips/pull/1823
I think this is a phase where the problem is that for the community there are more protocols than developers who are working on the same protocol implementation
Yes, this is the closest conceptually.
I have been aware of #communikeys and want to see it happen.
And you are right, there are a lot of specs and it's confusing but the exploration phase is naturally like that.
Hope to ossify around sth like communikeys, and I am leaning towards sth like this implemented for #Budabit in due time.
Budabit actually doesn't fully use nip29 yet, we never migrated along with #Flotilla .
- Flotilla left the channels/rooms concept behind, something I value because it helps frame chat discussions. Note that this is not supported by communikeys either.
- Communikeys has badges to whitelist content types but I may need richer moderation methods, like in nip29.
Right now for Budabit I want to make a decent social experience with advanced Git features happen, so it can be lucrative for open-source communities to join. Unique utility comes first. Flotilla has most things implemented nicely. It's enough for now.
After onboarding some communities and getting feedback, we will tend to the social features again, and re-evaluate the specs.