Idea: Nostr next step

[chmac]

Note

tl;dr: Brain dump of a potential next step

We've been at nostriga for a few days. We talked to a lot of people about some of the challenges in migrating trustroots over to nostr. How to responsibly and respectfully manage private keys for non technical users, so they can recover their private key even without our cooperation was chief among them. We also explored what kinds of apps or services we could recommend to trustroots members where they could use their nostr keys, which are also a culture fit. #26

There's interest in putting content onto our map. Given that the map was specifically intended to be a throwaway prototype, it seems like that's not the place to have other folks investing time and effort. So it's time to consider what is our next step on the nostr journey. What can we do that will take us in the direction of ultimately moving everything over?

Local chat

One idea we're exploring is to build a new trustroots feature around localised chat. Something akin to the CouchSurfing groups of old. A way to connect with other users in a city, without making a hosting request, and in a "public" space. It could be similar to our current notes map, but presented a little differently. As you zoom the map, the chats that you can see change. So if you zoom into a single city, then you only see messages that are posted in that city. We could also add replies. So you can see an original message and then a thread of responses to it.

Ephemeral

If we focus on chat, it likely makes sense to make all messages ephemeral. We need to consider exactly how that would work. Do all replies get the same expiry as the original message? Can replies last longer than message? Can a user decide how long the message should stay, or do we set some fixed duration like a month?

Areas not points

In order to start a discussion, you need to choose a zone on the map. By using plus codes, users can choose an area rather than a point. This doesn't always work perfectly, the areas can be too big or too small, or split in the wrong places. But in general it would offer a way to group messages rather than having several posts all side by side in a small area. (The first version of nostr-map worked like this, with a fixed size of area).

Challenges

Rather than building a prototype, this would be building a feature. To make that work, we'd need to solve some key challenges:

• We need the option to store private keys for users
• Users need to understand that nostr is different from trustroots
  • We need to communicate those differences, messages are public, can't be reliably deleted, and so on
• Notifications, chat is only useful if you see replies
  • This could be email based at first

Wild ideas

• Make it a native mobile app instead of a web site? As well as?
• Option to include other non-trustroots nostr content on the map

Details

• We should probably fill out better nostr kind zero profiles for users
• This should look similarly well designed to trustroots
• As a new feature rather than an experiment, it will be hard to change the schemas later

[kenflannery]

Like it! Trip Hopping also has the "discussion on map" kinda feature, so it's another easy link and something to pool our thinking on.

The areas-not-points is a good... point. Initially putting a marker on the map for the center of the area seemed like the thing to do, but that quickly becomes confusing as you may think the discussion is about a park or something but it's actually about the whole city. Adding a transparent circle radius to reflect the area is kinda fun, but with many markers/discussions, it gets real sloppy real quick. On a large screen having a sidebar with conversations is the way to go, on a small screen/phone, it seems like having a container in the corner/bottom of the map with either a preview or a count of "discussions in this area" works. There could still be markers if zoomed far out, but it comes down to the goal and flexibility.

The actual scope/context of the conversation can be saved in GeoJSON, along with bbox coordinates, then just a geohash of the center point solely for queries is sufficient. On Trustroots, it comes down to whether you want to limit the types of locations people can start chatting in... and are there threads, or an ongoing chat? Can people select an arbitrary region/radius of their chat? Can they start a chat about one bend in the river or a restauraunt? Or should granularity be fixed to the the city/local level, which is where old-school Couchsurfing "Berlin" or "Paris" type groups lived? And going the opposite direction, what if they want to start a "Europe" conversation?

I also see two different ideas here, one being threaded conversations and the other being an ongoing group chat for the area. Both are decent ideas, and both could exist.

The threaded convos, like "Who knows the best beers spots in Portland these days?" is a classic Couchsurfing kinda thread, could last forever and something people could reference long after people have stopped replying.

An ongoing conversation, that may or may not have expiring messages, is a little different and kinda fun. Sort of like walking into a room and saying "Hey! Just got here to Singapore, who else is around?". Messages like this could show up on the bottom of the map, hovering over them could show the bounding box polygon on the map for example, and becomes extremely interesting with location-aware notifications in the app.

I've been playing with a lot of these ideas, it just comes down to how much people want to focus on one particular aspect of this, but it would definitely make Trustroots feel more like a community, built right into the search page. Many people would take the extra NOSTR onboarding step to join the conversation, and they could still be lurkers in the meantime.

Just on a last NOSTR point, there are already people posting events (kind 1 mostly, but also events and classifieds/offers, etc) with geohashes that are interesting, or with pictures and whatnot, so the map is already pretty fun and random. Very cool that people are posting in whatever random app and we can now see it on the map, and also that when stuff is posted on the map (on Trip Hopping or Trustroots for example) people may see the thread pop up in their normal feed on whatever random app they've got going on and reply to it... I suppose this is the big point of NOSTR, but it's just fun to see it coming to fruition.

[shuesken]

I don't think building out the map as a feature beyond the current basic Notes functionality is the right move. I think even if it didn't happen on Nostr, "make people regularly use the map on Trustroots" would be a difficult task. I also think it pushes us into a technically challenging area of UX. People are used to quite feature-rich and slick messenger apps and any chat app that doesn't provide the same functionality will easily be seen as unattractive. I think people are willing to put up with subpar messenger features in Trustroots itself or ebay or property listing websites because it's a means to an end and you can exchange your actual messenger details soon enough once you get tired of the clunkiness.

I do think that rebuilding the Notes app on Nostr as a non-prototype to a similar point of polishedness as the rest of the site is a good idea. But I'd propose sticking to the basic Notes as we have them right now except you can also mark a plus code area rather than a specific point and adding some barebones notifications on top (i.e. email when somebody posts in your city or posts nearby a post of yours) is enough. If people do start chatting on it wildly by posting notes next to each other, we can support that usecase later. If people pitch meetups, then we do that. If people advertise particular bars, we can integrate a places API. Having a max expiry date will be helpful here as well for any schema changes that might happen later.

I think we should try to build out the rest of Trustroots functionality on Nostr and tackle the hard problems (boundaries of private and public and public-within-a-community, private key management) early.

I'm not sure what making a native app would provide here? The Notes functionality already works in the mobile TR app (or I guess the mobile website) to a similar level of ease as in a browser. I think building native apps creates a lot of overhead for us we do not need right now.

[chmac]

App vs web

One of the big challenges we face is storing private keys. Native mobile apps have access to the keystore / keychain. It's backed up as part of your phone backups. This means we can give the user the only copy of their private key, and it's unlikely they will lose the key or that the key will be misused. On the web, this is extremely difficult to achieve. (It might become possible in time due to webauthn PRF, but that will probably always be scoped to a single domain).

Ideally, key management will become more mainstream in the coming year or two, PRF might become more widespread, and then we might be able to offer a similar experience on the web as on mobile. This would allow users to recover their nostr private keys without our cooperation.

But until then, handling private keys online is hard. My suggestion of using an app to start with is as a means of bypassing that issue.

Chat vs notes

I'm not sure what the difference between chat and notes would be. It seems like in both cases we'd like to offer users notifications when things are posted in areas they care about. Chat would potentially add threads, although that doesn't seem essential, and might add complexity. My sense is that we're discussing the same thing, but using different terms.

I do think there's a strong history of having "communities" on other hospex platforms. On trustroots, there's no way to easily connect with other nearby members in a public fashion. It's only possible to send them private messages if they're visible on the map (~23% of users). Allowing all users to participate in localised discussion seems like an obvious expansion of the trustroots featureset which is well validated by other sites. There are, of course, also compelling reasons not to do that. Spam and moderation become much bigger topics for example, among other issues.

Building trustroots on nostr

My impression is that we're simply not ready for that yet. The key challenges I see are human and not technical. How can we communicate to a user that their new "key" is actually a digital identity and can be used across other sites, it's not just a "password" for this site? How can we frame the UI such that users immediately understand that when they post something, there's no guarantee it can ever be deleted, like with email? How do we handle private keys? I think these and a host of other challenges are fat better addressed on non core features, and should be robustly solved before we start migrating any of the core features.

[trentlarson]

App vs Web

It's true that the native keychain/keystore access is a more-robust way for everyday users to manage their keys. However, I see two reasons why a quick web app approach is useful: it will take more time to work on & release native apps, and the first adopters will be people who are familiar with password managers and can use them to manage the keys. I personally believe that the speed of deployment (even to the self-limiting set of tech-savvy users) is more important, along with desktop usage... and the more-robust key management can always be added incrementally.

Storing the key or seed in IndexedDB is not the most secure approach, but in all these tools there is a range of security -- just like managing cryptocurrency wallets with various security profiles for various amounts. In fact, there are differences in the security levels within an app, for example where the contacts may not need the same security as the identity key. The process to make a key uber-secure is a rather advanced option (which, like you say, may be easy someday but not yet)... so there is value in getting people started with an identity easily in a less-secure way and then letting them graduate to more secure options when they are ready.

Building trustroots on nostr

I would lean the same way here: build even one function for early users which might require some advanced understanding, and then start building migration paths for other users. Upgrades are now a part of all software lifecycles... so hopefully we'll have an easy path someday, but if we have real-life technical users who will actually use the features and give feedback, that experimentation and iteration is gold.

Just a couple thoughts on the side of getting to market quickly. :-)

[kenflannery]

NIP-07 is easy to set up, which lets users leverage a browser extension. I thought that was regarded as more secure than pasting a key into apps and whatnot, more convenient anyway. But, that convenience is only after the initial hurdle of understanding what the extension is, why you need it, and installing it. I've been using the approach of having that available on web and secure storage for the key on Android (or an option on web if you use it), but I don't know what the nostr world at large thinks about that.

[chmac]

NIP 7 doesn't work on mobile browsers, at least not on iOS, and probably not on android. So if we build for web, we need to assume users will have their own key without an extension.

[kenflannery]

Your right on that, it only works on mobile browsers no one uses, like firefox I think and some other goofy one only crypto nerds use I can't remember.

[Marmaladeskies]

Is it possibile for trust roots to completely handle users keys behind the scenes unless they opt to manage or export their key themselves? I'm not sure what this would look like exactly, but in the future there will be better options for key management and users will be more accustomed to that. It'd be great if there is a road to transitioning to a nostr integration for people who want to fully use TR but don't care about the main benefits of nostr, for now. Obviously having TR generate and store keys for every user and automatically authenticate nostr posts defeats the purpose of using nostr, but it would create a much better UX for the majority of users right now and would be a big move in the right direction.

[Marmaladeskies]

Also I'm not sure where all the lines are drawn between notes on a map and a searchable forum, but I remember that the loss of a traditional arbitrary group forum when couch surfing switched to the places based forum was a devastating UX hit. As I recall the old forum was simply moved out of sight so people stopped using it, and the replacement prioritized the most recent post near you and created a much lower quality ux for several reasons that may or may not be relevant here...

A places based wiki or faq is very useful. Also worth considering is what will ever be indexed by search engines, because the forum search rankings were a big part of TripAdvisors growth of users

[chmac]

I just deleted a comment by @masooddahmedd which seemed to be malware. I strongly advise against following the instructions.

[chmac]

That was another malware comment. I've locked this issue until GitHub can figure out how to block this stuff. I reported both posts and they already banned the first account, but it seems this issue is somehow attracting the wrong kind of attention. 🤷‍♂️

[chmac]

I was on my phone earlier, so I didn't really know what "locking" the issue meant. If you can't reply here, feel free to open a new issue and I can copy your contents here, or add you to the repo somehow. Sorry for the hassle, maybe we can unlock the issue in a week or so and GitHub have solved the malware issue. Or maybe I'm being overly paranoid and everybody reading here is smart enough to avoid the malware links. :)

[chmac]

Meeting this morning, we settled on a next step. I've updated the readme.