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

@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.

• 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

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

eec991e291ecf1868cf1fdb38c3fa83500b4334192ac518ba378e6d8ace477e4

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

• 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)

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...

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.

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.

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.

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

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?

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

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

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)

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

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

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!

discussion started at #18 (comment)

deserves a separate issue here

(feel free to edit this description)

NIPS

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