NIPS

• NIP-52: Calendar events
• NIP-99: Classified listings - we could use this without using the price metadata or price set to 0

thoughts about the web client

• we only care about the web app, others can and will build ios and android apps
• turn circles into #tags?
• forget about meet initially, it's hardly used now and we try a proper implementation later

parts that are mostly there in nostr clients:

• messages
• profile

essential and probably not there yet in existing clients:

• map search
• hosting profile -> #offer notes?

nice to have but not essential

• contacts, especially experiences

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.

The nostr community tends to be very bitcoin centric, which is not a good fit for the trustroots community. Are there corners of the nostr world which are a better fit culturally? If we can find some projects whose homepages don't read like a bitcoin maximalist bro party, that would be incredibly valuable as we could encourage trustroots users to experiment with them. Especially anything which fits into the gifting / no money space.

Firefox can’t establish a connection to the server at wss://nostr.zebedee.cloud/.

Create PR for https://github.com/aljazceru/awesome-nostr

Something like: "Nostroots: Trustroots is a hospitality exchange network of 100k+ members, like couchsurfing(tm) but free and more alternative. We're nostrifying it."

Which section?

https://nips.nostr.com/29

discussion started at #18 (comment)

deserves a separate issue here

(feel free to edit this description)

We want to run a relay that is only usable after authentication. #5
Both to send as well as to read notes from the relay.

There are several relays that support authentication for sending.
Are there any that support authentication for reading?

https://github.com/nostr-protocol/nips/blob/master/42.md

Relates to #4 NIP-05

Some pointers around ridesharing:

• it heavily relates to meet #12
• we have hitchwiki.org which has plenty visits from hitchhikers, so we can kickstart this if we focus on this target group
• we have rideshares.org and there's a repo https://github.com/Hitchwiki/nostrides

Every circle can have associated geo and event notes #10

For the hitchhiking circle: Hitchwiki/nostrides#1

This way if cool stuff like Hitchspots.me and Hitchlog.com is nostrified these tools will be immediately useful for other circles and it will be straightforward for people to innovate with geo notes from other circles.

The prototype works. At least, you can publish a profile and some info. It doesn't have private messages. They would be next. But the underlying code already exists in nostr-tools for encrypting messages.

• How do we handle the async data flows?
  • Redux?
  • Sagas?
  • Thunks?
• Do we store data somewhere?
• Do we keep subscriptions open? There's no clear need to unsubscribe.
  • But how do we feed data into React in that case?
• Write a nostr-redux layer?
  • Dispatch actions, get data from nostr, fill redux
  • Is using the browser storage more idiomatic?
• Do we cache data in browser storage?
  • Relays seem to be pretty quick so far, maybe simplest to leave this alone for now

tl;dr We’re organizing a Nostr Trustroots Collective this May near Berlin.

What

We want to nostrify trustroots.

When

Wednesday 22nd to Sunday 26th of May 2024.
Feel free to arrive a day or three beforehand.

Where

1 hour train ride from Berlin. Precise details shared with participants.

Why

In 2022 the main person behind Trustroots stepped away from the project, without even a message. When we realized email had been down for 5 weeks, we fixed it and made sure to increase the bus factor a little.

We think it is worth our time and energy to work towards gift economy social networks that do not rely on any specific person or organization, so effectively we want to make ourselves redundant. By moving onto Nostr development will become distributed and not centralized like it is now, so everyone can volunteer in their own autonomous way and with whomever they please.

Read more at https://github.com/Trustroots/nostroots

How, goals

Implement basic features in Trustroots that will make it possible for anyone to build Nostr apps connecting this.

• run a trustroots relay server or two
• only accessible to trustroots users
• utilize geo features
• trust on nostr, any related NIPs?
• build adjacent nostr stuff, e.g. for hitchhikers or other trustroots circles
  • nostr notes relevant to hitchhikers, also great for trustroots hitchhiking circle and hitchwiki
  • NIP-07 log in to mediawiki extension, great for hitchwiki and trashwiki

Wanna come join? Fill in this form.

(If you can't make it or want to participate remotely you can use this Google Form)

NOTE: We are not seeking general feedback on this nostr mission, but if you insist on sharing that, please do so in a new issue and not here. This issue is about organising the collective.

Logging test private keys here just in case we want to clean up our mess...

eec991e291ecf1868cf1fdb38c3fa83500b4334192ac518ba378e6d8ace477e4

• turn contacts and experiences into notes
• ideally thru NIP standard
• nice to display as map
• nice to display as graph
• nice to use FOAF connections (friend of a friend)
• this could be a separate app

In the README.md, there is a link to nostr.net:

[https://nostr.net/](nostr.net)

This does not work, as the link target points to the relative URL nostr.net. When the README.md is viewed just by opening https://github.com/Trustroots/nostroots, for example, it will point to https://github.com/Trustroots/nostroots/blob/main/nostr.net, which does not exist.

The link target needs to be https://nostr.net/, not nostr.net.

Regards!

We have a basic prototype running nostr-map. One way to expand that test would be to encourage users to use their trustroots created private key on another app. For example, adding some kind of chat feature to the map which is also usable from a separate nostr app. The task here is to research which apps or projects could be a good fit for this.

Some thoughts to consider include:

• What kind of nostr messages does the app use?
• Does the chat app send notifications somehow? For example, if it's a mobile app versus a web app and so on.
• Do you think the app maintainers would be open to collaboration? If it's a smaller app with few users, then promotion on trustroots could be valuable to them.
• What's the culture like? Nostr in general can be very bitcoin bro heavy, which is a bad fit for trustroots. Ideally we'd find potential collaborators from the nostr space which are more culturally compatible.

possible steps, not per se in this order, many of these should have instant gratification

• NIP-05 on trustroots.org
• set up relay server that only accepts notes from @trustroots.org users
• and ideally only allows sharing with @trustroots.org users
• show notes at https://www.trustroots.org/circles/hitchhikers
• connect with ~400 hitchhikers on signal/matrix group
• get more people to play with this in other ways
• heuristics to map notes to other circles if appropriate (e.g. dumpster, trash)
• add geo data to notes
• build hospitality-style features
• build map-like features, could be hospitality, but also hitchmap, trashmap
• run an additional relay on another domain

Daemon to remotely sign nostr events using keys. https://github.com/kind-0/nsecbunkerd

Post by @zweifeln

I hate to do this.

I love open source. I love the sharing economy. (Though I don't really believe in the "gift" economy. Gift and economy doesn't go together. But that's beside the point.)

Every de-central approach; every maintained open source project has someone (or a rather small group of people) who take care of it. Sometimes they have a business model (like my employer does), sometimes these people have a different form of income and do it as their hobby. That's great. Sometimes these people will stop maintaining things and then half the internet may break. That's bad but it is how it has been the past 30 years.
I strongly believe it is very helpful to acknowledge that before going forward with any decentralizing idea.

Someone is actually in charge.
Someone needs to write the code and maintain it. Install updates and keep the servers running. Yes, software can update itself - but only as long as the updating part of the software itself works all fine. Software the harddrives need to be changed and sometimes software just breaks. Then there is need for someone who knows what's happening. So we rely on them.
That is the case no matter how good a programmer one might be. If you didn't work with that software, you don't know the libraries and frameworks.
We're having this topic here on Github. A platform owned (and maintained) by microsoft.
The only really free, decentralized software widely used out there … is e-mail. But who of you actually runs their own e-mail server? (I don't. It's too much pain.)
The point cannot be to be totally independent. Yes, that sounds nice but in reality it means, you are alone.
The point is trust. The thing that is already in our name. Some people have the knowledge and willpower to develop software and run it. Others will trust them and use it. That is okay. And that means, the people not running the software will trust their platform. Or not - then they will leave the platform.
Similar to how not every human on earth is making their own bread. Most of us are just buying it in a bakery. (Or don't eat bread). It is not sustainable for everyone to make their own bread. And certainly not practicable for everyone to grow their own grain.

We rely on people not on software. That is a good thing. Let's acknowledge that.
When we do that, we can go forward and make some system that is easier to maintain and better usable to more people - also non tech-people.
Running decentralized software is - unfortunately - not actually decentralized. No matter how easy it seems to tech people. It may seem easy for us who we are comfortable using Github. But it actually is quite elite. Most people I have met traveling the past 8 weeks don't know what Github is.

The point is not the software. The point is how to make it sustainable. How to have a community that is trusting each other and how that spirit might continue even when central people step back for whatever reasons. There are lots of good reasons. So often people get pressured into keeping a central role as it all would fall apart if they step back. But maybe they got sick or take care of sick people or children or maybe they are just tired after doing it for so long and actually just wanna travel themselves and enjoy live.
The the hard question is: how to keep things running. How to make sure the community has enough trusted people to step in if someone steps back. How to develop and maintain a beautiful community.
That is more a philosophical than a technical question but that is the central question.

Originally posted by @zweifeln in #11 (comment)

Here's a little essay that I had thought to tell @guaka by phone!

I was thinking this morning about the nostr experiment. What can people do on it? That's the question I focused on. Replicating a poor quality copy of the current trustroots experience doesn't make a lot of sense. Folks might use it, but presumably they only use it if they're really motivated to try nostr, or just love p2p, etc. Otherwise, why bother?

Which led me to consider, what about putting something else on nostr? A few ideas came up:

1. Events, start time, end time, location, description, show events sorted by date in a given location...
2. Real time chat per circle

• This might not be the best experience if there are no notifications
• We could probably rig up something to send emails when people receive messages, but that will require a bunch of custom server side code I believe

3. A forum style of discussion, something where it's more expected that you won't get immediate replies so notifications won't be such an issue
4. A question & answer style site, stackoverflow but on nostr
5. Other kinds of gifts, which could be anything, shown on a map

• The obvious challenge with this seems to be that if nobody uses it, it's kinda pointless to put a gift on it, chicken and egg problem...

6. Tour guide type recommendations, stuff that's recommended by trustrooters to see in a given location
7. Notes with locations, put any text with a location and show them all on a map
8. Expiring notes with locations, same as above but they expire after 1, 7, 30 days or something

What else?

Thoughts

Personally, I think it makes sense not to put hospex on nostr at first.

We could also launch a simple demo without doing any trustroots integration. It just gets linked from trustroots. It might get spammed. We can see how it goes. Most likely it'll simply be ignored.

I'm leaning towards starting with simple notes and adding a location. We don't need to add any extra functionality to nostr to be able to do that. We can just designate a location field and then crack on. We can load all the data on every page view. If that becomes problematic we could react accordingly.

I'm liable to proceed with something like this unless I hear contra feedback or better ideas are proposed...

@guaka started writing a blog post...

tl;dr - We want to make sure that Trustroots exists 2 decades from now and unlock sharing beyond hospitality: rides, bicycles, meals, parties, etc.

Trustroots has already had a brush with death. The project lead stepped away without a word. Only one other person had access to most of the servers. We've seen the same issue with other hospitality sites. CouchSurfing took venture capital investment which slowly rotted out the site. Warm showers had major management clashes. Hospitality Club has had long periods of downtime as there's only one person running it.

Instead of just having one Trustroots, with one set of administrators, we want to have many. A network of connected sites. Maybe focused on different things. Some focused on bike tourers. Some on sharing rides. But each user's data, it lives across multiple sites. The user themselves has control over the data. If one site dies, you can log in somewhere else and still keep all of your connections, messages, and references. No one person can step away from the project and have it all come crashing down.

Plus, people can start sites with new features. Instead of sites like couchers starting over and building a network from scratch, they could start from the Trustroots users. When trustroots user logs into to a new site, all of their data comes with them. This is the major challenge for all new networks. When there's nobody on the network, it's not very useful. This makes it hard to experiment, to try new features. Hopefully, we can, slowly, make this easier.

We hope this is possible on something called nostr. We've looked at other decentralised technologies, but nostr is the first option that seems like it might work.

We don't have the illusion that we can move all of Trustroots over to nostr in a year. But we don't need to. We can enable small parts and then others can build on these foundations.

• https://github.com/nostr-protocol/nips/blob/master/05.md
• https://thebitcoinmanual.com/articles/nostr-account-nip-05-verified/

Seems easy to implement early 2024:

• npub field on user profile, which is not displayed initially
• GET https://www.trustroots.org/.well-known/nostr.json?name=bob returns appropriate JSON "names": { "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9" } }

UPDATE: better provide nsecs for everyone right away

• nsecbunkerd #17
• .well-known/nostr.json
• show npub and NIP-05 on profiles (

probably add another section here, replace ELSEWHERE with NOSTR:

(and NOSTR can even link to a page with apps that can use this)

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 [email protected].

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:

• circle chat #13
• meet #12
• rideshares #19

Comments very welcome.