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

Current state and roadmap #18

Open
guaka opened this issue Mar 19, 2024 · 6 comments
Open

Current state and roadmap #18

guaka opened this issue Mar 19, 2024 · 6 comments

Comments

@guaka
Copy link
Contributor

guaka commented Mar 19, 2024

Current state: there is a basic nostr app in this repo but it is no way connected to the web app running at trustroots.org.

Before we get to a roadmap we first need to clarify how we want to approach this. So I will just write down some of my thoughts.

Rewriting the entire Trustroots app based on nostr is too much, the architecture of the app isn't great. I think it's better to slap nsecs (e.g. with #17) onto user profiles and enable NIP-05 #4 so that trustroots users can use any nostr app as user@trustroots.org.

Now if we build one or more basic nostr apps we can encourage people to use these. Good candidates are something around chat and location, we can use geo tagged nostr notes for this #10. Since the current Meet functionality is hardly used by anyone we can rip this out and instead link to a "Beta" page that shows these apps (@chmac idea). App ideas:

Comments very welcome.

@guaka
Copy link
Contributor Author

guaka commented Mar 19, 2024

The above were my thoughts around the client/app side.

I think it makes sense to play with #9 authenticated relays, ideally only use our own relay on which only trustroots.org users are allowed, and let people choose to use unauthenticated relays in the future.

@Marmaladeskies
Copy link

IMO the most important advantage to shifting towards decentralization is the portability of a network of experiences/references. They are critical to establishing an initial offer of trust to strangers at any scale, and they take time to build up to the point of being helpful. The centralization of experience data creates the bulk of the obstacles that alternative projects face in gaining adoption. If nothing other than experience data (and a simple way for other projects to interact with it) was decentralized, it could be a serious step forward for hospitality and exchange networks.

@chmac
Copy link
Member

chmac commented Apr 6, 2024

@Marmaladeskies Agreed, this is a key challenge, which also raises the issue of abuse prevention. If I can flag references as spam, how do I stop people flagging my negative references as spam?

Although I will say that Trustroots has very few experiences, and at ~100k members, the network seems to work fairly well. So this might only be a problem in larger networks or beyond a certain point of growth. Having multiple interconnected smaller networks with their own gatekeeping policies might go a long way to building sufficient trust.

@Marmaladeskies
Copy link

If I can flag references as spam, how do I stop people flagging my negative references as spam?

I think leaving a review would require permission from the owner of the profile, like a Bluetooth pairing. But like a smart contract, once approved, the owner can't revoke it. Otherwise, without centralization, the system could be ruined by a spam attack.

I guess if the goal were not fully decentralized apps, the decentralized reference data could be riddled with spam, & centralized websites could create their own filtering rules. Then there would be less incentive for a spam attack in the first place. But I suspect that system still wouldn't scale well.

I would guess couch surfing was large enough that they wasted a lot of support hours dealing with reference disputes that would not be easy to automate, and which could have been avoided by requiring permission. I know they removed the ability for authors to edit old references and made them read only. When references could be edited the disputes were never ending.

An issue with making references permissioned is that users need to be pre-authorized to leave a review before they meet. They would need to accept an invitation to meet in person that also grants permission for a reference. Otherwise there is no way to leave a negative reference for someone who knows they should get a negative reference and rejects the request.

Then you have to rely on prominently listed profile creation date and reference date/time stamps to make fake positive reviews look suspicious (I don't think users creating fake accounts for positive reviews was ever much a problem on any of the hospitality sites).

@guaka
Copy link
Contributor Author

guaka commented Apr 6, 2024

let's continue/move the discussion about references/reviews at/to #20

@guaka
Copy link
Contributor Author

guaka commented Apr 10, 2024

related: new blog post at https://ideas.trustroots.org/2024/04/10/moving-trustroots-onto-nostr/ see also #21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants