Subnostr

So is your implementation compatible with anything? Or YAEGS (yet another encrypted groups standard)? NIP 24 doesn't use a shared key, but it well-supported and quite good for smallish groups. NIP 87 is more ambitious, and similar to NIP 112, which has support in ArcadeCity. Any rate, I'd like to see the details of your implementation and figure out something that will work for everyone.

Water Blower 2y ago

The implementation is very similar to NIP-87. Some details are different. For example, meta data leakage is much smaller. Group members are not tagged.

I might consider switching to gift-wrapped event after some examination.

NIP-112 is way to big.

The key features in my design is that:

1. only use one kind

Creation, invitation, acceptance, message are all the same kind. Their data are all encrypted. Only after encryption, the receipient will know what kind of group event it is.

2. Minimal metadata leakage. Only receipient or group key are tagged. All other metadata are encrypted.

One obvious problem with gift wrap or similar approach is that authenticated relay might have a hard time.

Unless authenticated relays use a separate auth-token instead of pubkeys to identify users.

Reply to this note

Please Login to reply.

Discussion

hodlbod 2y ago

There are lots of tradeoffs here, it would be nice to design the solution collaboratively rather than forge ahead independently. I have tons of thoughts on this topic as far as what I hope it can support. Is there a NIP?

Water Blower 2y ago

There isn't a NIP yet.

My methodology is to get UX right first, the implementation can be changed later. The problem with writing a NIP up front is that the design was changing during our implementation. Reviewing a NIP without real software to try out slows the whole community down. Writing a NIP after implementation also means now we understand much deeper about the problem. The NIP later on will be better quality.

nostr:nprofile1qqsverg89m7ucem0ewkpfakddqj7ms6hde27k7r292t4acp556szdjcpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqscamnwvaz7tmzwf3zu6t0g2ep0q will write a NIP or at least that's what she proposed during the meeting LOL.

nostr:nprofile1qqs2mvf775w8q882vwuza4ql22yr387yq50ppvfup0l6wlnav8yed0gpr4mhxue69uhhyetvv9ujumn0wd68ytnhd9ex2erwv46zu6nsqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsxwfdau still needs to finish up some UI. But the logic is already in the production, we just hide the UI.

The plan is to release this feature for testing by the end of Friday and then Sherry or I will draft a NIP.

If we are productive, we can release it on Wednsday.

hodlbod 2y ago

This approach is fine, I just wouldn't push it to production. The draft nip I wrote helped me think through what I wanted. I have already implemented nip 87, but in doing so found some problems. It's on ice until NIP 44 gets merged, at which point I want to fix the issues I found, and maybe walk things back to trusting relays to do some auth.

hodlbod 2y ago

Looking through the source I'm honestly kind of disappointed you didn't loop me in on this. I spent about 3 weeks implementing my version back in August, and this implementation just isn't going to work for my use case (nostr-in-nostr). Unless I'm misunderstanding how it works, this is just a different way of doing feature-poor group chats. You're right that wrapping is maybe problematic, but the solution isn't to create a bespoke protocol specifically for groups, this is the thing fiatjaf is always talking about.

hodlbod 2y ago

Sorry, not suggesting you did anything wrong, nostr developers just need to start working together more on this complex/fundamental stuff

Sherry 2y ago

He had some trauma on verbal communication about his thoughts on nostr…

Water Blower 2y ago

I am not offended and the point of hacking ahead is to understand the problem space. There are many features that I have discussed with nostr:npub14kcnaaguwqww5cac9m2p755g8z0ugpg7zzcnczll5al86cwfj67sjk2chk but we don’t have enough engineering power to implement just yet.

Since group chat is a feature that we will implement anyway, at least from my perspective, it’s more prioritized to get the common UX right before finalizing any particular implementation.

I also need to refactor the code base to a state that implementing group chat is possible.

So even if Blowater ends up throwing away all current implementation, the effort is not wasted.

hodlbod 2y ago

Good to hear, keep me in the loop as you put together a standard, hammering groups out is my top priority

Water Blower 2y ago

It was 4am yesterday and my brain was dead. Looking back at the conversation, we (you and me and other devs) should definitely work together. But we need to have a rough consensus about what it means to be working together. NIP discussion, codebase etc.

But even before any of these material outputs, we need to figure out what each client dev is trying to do at the first place.

We need to figure out the product difference and similarity among clients. Sometimes, one client, Blowater for instance, might just have very different design goals.

But I can't be certain because we never discussed our design goal, product goal and potentially business goals.

Therefore, 2 suggestions:

1. We should definitely have an in-depth disussion in Tokyo.

2. We should (or mostly I shoud) engage in more public discussions about product designs.

Regarding feature richness, you are right. The current state of Blowater's GM is poor and it's intentional.

The core design is extensible enough to implement many useful and interesting or even weird features on top of it. But in terms of user experience research, I would like to be conservative and only let users to do minimal features at first. Once we have a solid foundation, we will be more confident to implement more features, progressively.

And I firmly believe that Release Small & Release Fast is a superior approach than a longer up-front design circle.

hodlbod 2y ago

For sure, excited to hear you're going to be there!

I have a different design philosophy I think, which is to create robust abstractions and then limit them at the application layer. This bites me sometimes, but if there's follow through I think it works.

So nip 87 is "the kitchen sink plus some other stuff", but in practice only some parts will be supported (similar to the protocol itself). This means that you get greater interoperability, because multiple features work based on the same abstractions.

The flipside of course is that if you overload an abstraction, you have contention over semantics. But nostr's kinds basically solves that problem and as far as I understand the problem we need only two kinds of encrypted messaging support in nostr: one-to-one messages (scalable to groups using duplicate messages), and many-to-many messages (scalable using a shared key).

Anything in addition to those (moderation, administration, relay selection) can be rolled into either abstraction as an independent component, I think. Of course, my entire approach may change, as I shift back to exploring how relays can solve some group stuff on their own, without encrypted channels.

Water Blower 2y ago

Yes, the main difference is the design philosophy here.

Water Blower 2y ago

What is Nostr-in-Nostr?

hodlbod 2y ago

E.g. a kind 7 sent over an encrypted channel. It enables private calendars, private profiles, etc