Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in-app chat #993

Open
brenzi opened this issue Feb 7, 2023 · 1 comment
Open

in-app chat #993

brenzi opened this issue Feb 7, 2023 · 1 comment
Labels
enhancement New feature or request Epic F1-shallow-encointer-domain Needs a bit of encointer domain knowledge

Comments

@brenzi
Copy link
Member

brenzi commented Feb 7, 2023

problem statement

For communities, it is not easy to choose a suitable bidirectional communication channel. Most options nowadays are proprietary, centralized and require an account. And the worst thing is that the audience is scattered and there is just no common ground.

For Encointer communities, the single tool with 100% coverage is the Encointer Wallet App itself. So why not build a chat inside the app?

Nostr protocol

Building a chat application from scratch would be a defocus of resources, but the nostr protocol is already out there and it is very unopinionated about how it should be used. This makes it an interesting choicem with tools and libraries already available

Success Scenario

  1. one bootstrapper creates a channel (NIP-28) and defines title, about and picture
  2. the community adds the channel id to community metadata onchain (could be a file on ipfs, like the community icon. no strict need to extend metadata struct)
  3. the creator delegates signing to moderator accounts on nostr
  4. the wallet app looks up the channel id for the selected community onchain and applies moderation events and paywall on client side

Caveats:

  • public channels must be created by a keypair. the only special authority granted to this keypair is updating channel metadata (name, about, picture). How can we get rid of this "trusted setup" and hand this privilege over to chain governance?

Encointer Chat V0.1

A read-only view in the Encointer Wallet app that just subscribes to new events in hard-coded channels:

  • a per-community channel (to be specified in community metadata onchain)
  • a global Encointer channel (also to be set onchain to make it subject to governance)

Requirements

Such an MVP nostr client would need to implement:

  • NIP-01 basic protocol
  • NIP-28 public chats (mandatory event kind only: 40/41/42)

Encointer Chat V0.2

Allow content moderation. A tricky one, but lamentably indispensible.

Requirements

  • NIP-09 event deletion by author
  • NIP-28 public chats hide message and mute user (event kind 43/44)

Approaches to moderation

paywall for spam prevention

reading is public and free, but writing to the chat could be paywalled to prevent spam. A user that would like to post should prove that he/she owns a minimal amount of the respective local currency by making a minimal payment. This could be a one-off payment with eternal membership afterwards, or yearly?
There should be no linkability between encointer account and nostr identity. For privacy reasons (because people tend to de-pseudonymize with their chat profile), but also to avoid collusion (looking up who your fellow cycle gathering participants are and try to bend the protocol). A possible solution could be MMR PoR

representative moderation

One nostr account is elected by community on-chain democracy to be the moderator. the client checks for hide or mute events for every note before displaying it

caveats:

  • accounts can delegate signing authority (NIP-26), so an elected moderator could pass on the privilege with undermines the election - but allows for multiple moderators. This is not as bad, because the community could change the channel id by onchain governance to switch moderators
  • moderators can use other nostr clients with more features, however, they must be aware that their hiding and banning will be applied for everyone and the UI may not explicitly show that (maybe through delegation it becomes obvious?).

cancel-first

Every user can send kind 43 (hide message) or kind 44 (mute user). For each note, the client will check how many users voted to hide or mute and will do so if a threshold is reached

Extension: reputation needed to moderate

Encointer Chat V0.3

Allow people to post and customize their identities

  • NIP-06 to generate a nostr private key from the encointer wallet account seed phrase (verify that no linking to wallet account is possible for privacy reasons)

Later

  • NIP-13 enforce PoW for spam prevention

Implementation Options

There is a dart package, but it doesn't support the minimum NIPs for this
https://pub.dev/packages/nostr
We may need to contribute....

@brenzi brenzi added enhancement New feature or request F0-pure flutter Flutter taks; does not need F1-shallow-encointer-domain Needs a bit of encointer domain knowledge and removed F0-pure flutter Flutter taks; does not need labels Feb 14, 2023
@brenzi
Copy link
Member Author

brenzi commented Feb 19, 2023

unlinkable personhood badges could be done with this: encointer/encointer-node#300

The wallet app would:

  1. either generate a new nostr privkey or ask the user to provide one
  2. request a badge from the oracle on behalf of the new nostr profile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Epic F1-shallow-encointer-domain Needs a bit of encointer domain knowledge
Projects
None yet
Development

No branches or pull requests

1 participant