Yep, but managing multiple accounts per topic gets annoying very quickly. It's hard to visualize people adopting it.
Discussion
⭐ The Official BNB Airdrop Is Live.
⭐ https://telegra.ph/bnb-09-02-2 Claim free $BNB.
All clients already support it
Adopting moderated communities is a bigger ask. Its complicated and has opinionated moderation schemes. This would work out of the box in all clients and is just UX work for making it nice when composing
The work of composing multiple keys in the same UI is feels larger (fundamentally different architecture) than the work to implement communities. Then users will have different accounts and for each account different sub-accounts, which can all have more sub accounts... etc.
Also, you don't need to support actual moderation for this.
This complexity is not imposed on any other client. I can’t see how building whole reddit style communities into UIs is easier.
Right?
Well it kinda is. Every other client will see different accounts and not subaccounts nicely merged together. People will have to follow 5 Wills, one for each topic. They will appear duplicated as if they were different personnas, which is not the expected UI on the Damus user.
Imagine seeing 5 Will with my the same picture and then a 6th as a scammer. Everything gets more confusing to those not merging subkeys as one.
I am not against the idea. It's just not as "free" as you are describing.
Good point
But don't talk him out of it >_<
Thats the whole point, i dont want people following them unless they explicitly want to. I dont want them on my main account.
Im also not against a separate kind but pubkeys seemed more backwards compatible with other clients and moderated communities doesn’t seem it either
Fully separate identities are backwards compatible and will work well in all/most clients.
The Damus' user creating 5 or 15 accounts thinking that people will only see one of them, or a UI that nicely manages together, is not backwards compatible at all. It breaks the UX for everybody else.
to other clients it would look like regular accounts. If other clients don’t support subaccount listing then thats fine, you can still discover the posts using existing techniques
What you are telling me is that you don't see how not supporting subaccounts breaks these clients user experience. That's fine, but I am telling you, it will suck for them. It will become very confusing if this becomes highly used.
I am saying this because the average Amethyst user has 2+ independent accounts logged into in the same phone. So, I know people will use this if you develop it. The difference is that with Amethyst they are different personnas. They generally don't share the same name or picture. So, It doesn't break the user experience. It's a clean separation.
But they are not different, it will be very confusing for those not implementing it.
I never said they had to share the same profile
Correct. But you also didn't say they must be different. If the default is going to be the same, then it will break the UX. Otherwise it can work.
I really don’t know what you’re on about. This doesn’t affect your client at all
🍿
Like I said, it depends a lot on how you implement.
You can make it backwards compatible by just implementing in a way that they look like fully different accounts or completely break backward compatibility by making these accounts look similar.
I still think implementing communities is way easier than any of this, but I gave up trying to convince you so. :)
Do both. From a user end, they both support each other.
Though nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ‘s idea grants the individual more control, and lets us build our own community.
More or less, are you showing notifications for all accounts in a single view? Same for DMs and chats? Can people message the sub account?
People would send messages and interact normally with the second key and thus either user treats them as fully separate accounts (which every client can do) or clients can try to merge all sub keys in the same profile. But that requires implementation. No one has the later yet.