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.
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.
Discussion
Sorry, not suggesting you did anything wrong, nostr developers just need to start working together more on this complex/fundamental stuff
He had some trauma on verbal communication about his thoughts on nostr…
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.
Good to hear, keep me in the loop as you put together a standard, hammering groups out is my top priority
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.
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.
Yes, the main difference is the design philosophy here.