NIP-72 for Developing a Decentralized TR Platform

[guaka]

copied here from https://pad.riseup.net/p/to2tz1IAWj06zPN3pUIF (mostly not my work except for fixing some typos etc)

TRIP-01 TRustroots Improvement Proposal

We propose leveraging NIP-72 to develop a decentralized TR platform. After evaluating various NIPs, NIP-72 stands out as an equally sensible and feasible approach.

It follows a rough outline to make the main technical spec easier to follow:

• The core functionality involves users posting offers, profiles, and other actions as nostr events. 30397. These events will then be approved and signed by a NIP-72 TR moderator (30398), guaranteeing authentication and authorization as well as preventing spam and other abuse.
• For private communication, NIP-17 messages will be used to facilitate direct messaging between TR users.
• Sign-ups will still require an email account and verification. This offers the same spam protection from sybil attacks as now, which seems to suffice. At signup, we will offer a choice between a BYOK (Bring Your Own Key) approach and an IDKAK (I Don't Know or Don't Care About Keys) approach. Keys can also be exported at any point by the user. (This implies key rotation which is feasible because we are using 30xxx events, meaning we can rotate keys and then update and resign moderation messages)

Although there are minor issues to address, such as image hosting and out-of-band user notifications via email, these can be seen as difficult and without a straightforward solution (one due to Nostr not having a solution for decentralized image sources and the other due to private messages meaning we do not know who the sender of a message is). These challenges have multiple existing solutions, albeit not the most elegant ones and all not without trade-offs. Our focus remains on solving core problems, which appear to be manageable with sufficient elegance.

Profile Event

Kind 0

content

name

about

profile_pic (HARD)

Offer Event

Kind 30397 (updateable)

content, text description of the offer

tags

d: client-generated-unique-id

L: open-location-code, l: 22222222+222

Where this is, at some level of imprecision

L: open-location-code-prefix-6, l: 222222

The olc prefix so we can filter for this

L: open-gifting-spec, l: wheelchair-accessible

tags:

[L, open-gifting-spec]

[l, wheelchair-accessible, open-gifting-spec]

Query would be:

#L: open-gifting-spec

#l: wheelchair-accessible

Alternate idea:

L: open-gifting-spec, l: ogn-wheelchair-accessible

Query would be:

#L: open-gifting-spec

#l: ogn-wheelchair-accessible

L: open-gifting-spec, l: really-wide-open-eagerness-person-1-million

L: open-gifting-spec, l: ogn-can-host-6, ogn-can-host-5, ogn-can-host-4, ogn-can-host-3, ogn-can-host-2, ogn-can-host-1, open-gifting-spec

Alternate idea:

Query: ogn-can-host-3, ogn-can-host-4, ogn-can-host-5, ogn-can-host-6...

Moderation Event

Kind 30398

content: ""

Tags

d: 30397-author-public-key:30397-d-tag

L: open-location-code, l: 22222222+222, open-location-code

L: open-location-code-prefix-6, l: 222222, open-location-code-prefix-6

Copy other L/l tag combos, after some validation

Ideas

Add some kind of L:open-gifting-network-tribe, l: tribe-uuid

Some summary of the user's trust as defined by trustroots

e: 30397-event-id

This would link us to uniquely identifying a single 30397, if that event has been replaced, then our link would no longer work, rather than pointing to whatever the latest version of the event happens to be

FAQ

How does this approach allow us to combat spam?

Firstly, we maintain a list of all trustroots users and their public keys. Then, if a user who is not a trustroots user posts a 30397 event, we will not post a matching 30398 events. As clients should search for 30398 events, then anything we don't approve won't be included on the map.

If a site like triphopping.com also uses the same approach, interoperating could look like triphopping asking each user if they want to see "trustroots certified users", "triphopping certified user", both, or potentially "everything including potential spam". The everything option could query for 30397 events instead of 30398. When querying for 30398 events clients should specify a set of public keys that must have signed those events. That means if a user posts a 30398 event directly, it won't be included in the query, and so won't be shown on the map.

How do we handle users losing their private keys?

As we control (and publish) all 30398 events, we can just update them. If we believe a user has a new private key, we can remove all 30398 events that point to their previous events, and instead point to their new events. In effect, we can moderate what is shown on the map, but if we start making bad policy decisions, clients can decide 

How do we query for data?

Essentially, the idea is that users post events, and we watch for those events and post "we approve of this" type events. Then our clients search for the approval events instead of the original.

That means, if we change the format of our filters, we could update our approval events to include the new filter format. This is possible even though we can't control the private keys of all our users. The original user's event may not be updated for years, meanwhile we could go through several versions of the format for approval events.