Subnostr

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.

Reply to this note

Please Login to reply.

Discussion

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.