BNS does not have group names built in as part of the implementation/protocol, correct?
Neither does Nostr. This means that to do things like send tokens or a messages to a group of entities it’s left to the applications. Also, the group names and member associations (data store) are then centralized. And this would make interactive use of group names between apps difficult.
Eg, #Trajan could create groups of users but they would not be easily addressable/referenced in other apps.
Does it make sense to have group names as part of the BNSx base/protocol?
cc: @hank @RagnarLifthrasir @larry
total off the wall thought…what if the data defining groups and group-members was stored in Ordinal space? Say Group names and user names such as *.ENS *.BTC *.SOL etc. were stored there such that a Group name (eg. “MegaPunks” or “YoloKings”) can have names from multiple/any of those user names.
Could it aid in cross-chain identity interoperability? Any app or chain that wants to use these public names can read them from Bitcoin Ord space. But how to update these records while keeping the pointer to each consistent/unchanging? What about update frequency? And would high tx fees make this unfeasible?
I’m guessing this is prob not the first time this has been mentioned.
Thoughts? @diwaker @larry @hank
1 Like
This is an interesting concept!
My personal take:
- this would work really well as a protocol/extension/feature that utilizes BNS/BNSx composability
- this might not make sense as a “core protocol” feature, as the use case is likely context-dependent and not super generic
You could absolutely do this today with a smart contract (or even ordinal) that keeps track of the state of users in the group. There are lots of ways that we can store state around “these BNS names are a part of this group”, and we could even register a name for that group (especially if it is a smart contract).
What you do next, though, is dependent on the use case. For Nostr, I could imagine some custom protocol that:
- looks up the bns name
- somehow determines that the name refers to a group
- looks up the Nostr keys in each of the group’s names
- somehow does a bulk dm/mention etc
A lot of that is “external” to BNS - like how a Nostr client should handle the situation.
I could also imagine a multi-sig that uses a similar “group”. In that case, you might want different dao-like features for adding/removing members based on some rules. And then you might want custom rules for how any of the assets are split between the group (like a multi-recipient royalty).
Either way, these ideas are do-able today without core contract/protocol changes, which is why I’d say it probably doesn’t make sense in the “core protocol”. I could see how standards could be formed around these use cases, and that could apply here to ensure consistency
2 Likes
I like the concept and see the utility.
1 Like