Ideas for reading Nostr events inside Minds
The Nostr integration proposal at #2311 (closed) and its current implementation efforts only enabled Nostr users from the external network to follow Minds users and see events from Minds users. The reverse flow -- Minds users being able to see events from the external Nostr network -- is trickier and some decisions around tradeoffs must be made.
The simplest possible flow
The simplest possible user flow could be to allow Minds users to type Nostr pubkeys or NIP-05 Nostr addresses on the Minds search bar, then query a list of hardcoded known public relays and if something is found, then show the Nostr user profile and latest posts in a view that could be the same as the Minds user profile view (but with something there saying that is not an actual Minds profile), then allow the Minds user to subscribe to updates from that Nostr user.
The actual "subscribe" step must be saved on the user list of subscriptions somehow, probably on a separate column or table nostr_subscriptions
or something like that, along with the pubkey the relay URL must be stored. Aside from that, I can think of basically 4 ways of doing it:
- Do everything on the client side. I think it's possible. The Minds frontend would query both the Minds backend for internal stuff and Nostr relays when searching profiles. In this case when alice@minds subscribes to bob@nostr the relays in which Bob publishes his stuff should be stored along with bob's pubkey in the list of Alice's
nostr_subscriptions
. And whenever Alice loads her Minds frontend she gets the list of Nostr subscriptions and opens websockets to the relays -- then the posts from Bob are mixed in with the other posts she gets from the Minds backend and displayed in the same timeline. The advantage of this method is that Nostr was kinda designed to be used from clients, that's why it has the websockets thing with live updates -- on the other hand it feels hacky and involves duplicating this code over the web client and the react-native client. - Do the same as 1, but preprocess the Nostr stuff on the Minds backend. When Alice opens minds.com the Minds backend fetches her list of
nostr_subscriptions
along with the relays these subscriptions live in, then queries these relays for the latest posts (by opening websockets, getting a bunch of events on them, then closing them), hoping for the best, then formats the Nostr posts as if they were Minds' posts and sends them back to Alice mixed with the internal Minds posts. This is probably cleaner as it doesn't require modifications on the client-side at all (except for some UI indications that stuff is from the external Nostr and not internal Minds), the problem is that the backend may get pretty hacky on this one, so I think it's not very good. - Preprocess stuff on the server like on 2, but instead of querying Nostr relays with websockets every time, keep a background job syncing all posts from Bob (only Bob, since Alice has subscribed to him) into a
nostr_events
table inside the Minds database. This way it becomes very simple to query Bob's posts and mix them with the internal Minds posts every time Alice opens minds.com, no more websockets or unreliable external relay connections, just query the database. Thenostr_events
table could be a very stateless thing. It's no big deal if it gets wiped out as it can be rebuild from the relay sources later if necessary (Minds makes no promise of providing free storage for Bob, as Bob is not even a Minds user), if Alice cancels her subscription to Bob and no one else is subscribed to Bob, stop syncing his stuff and maybe wipe it out and so on. One advantage of this method is that it allows other networks to be integrated besides Nostr in the future and they're all clearly separated in their dedicated database tables. - Do the same as 3, but instead of saving Bob's posts into a separate table
nostr_events
, do turn Bob into a Minds' "virtual" user. Make an account entry for him, put a tag "nostr" on it, make its username be something like<pubkey>@nostr
and every time a new post from him is spotted on a Nostr relay, copy it to the Minds database as if he had submitted it like a normal Minds user would. The advantage here is that there are basically no changes needed at the backend, only on the background job that will keep syncing stuff. These "virtual/nostr" accounts can also be stateless as in 3, there is no issue in wiping them out as they can be later recreated very easily (one thing that may be dirty here is assigning uids/guids for these virtual accounts and posts -- it would be nice if they could be derived deterministically from the actual Nostr pubkeys and event ids, I think it's possible). One advantage of this method is that it allows "converting" Nostr users into Minds users easily later if they want, although this brings the problem of if users would give their independent Nostr private keys to Minds when converting (or Minds could just politely ask them to sign every post they make from inside the Minds interface after the conversion), but this is irrelevant for now.
Now I don't know enough to say which one of these is best, but if I were to pick I would do 3 as it feels the least hacky and cleaner of the methods above -- although I could justify myself doing 1 or 4 too.
Maybe there is a better method I didn't think about, but I hope the write-up above have helped giving you some inspiration.
Tagged events and public keys
What happens if alice@minds is subscribed to bob@nostr and Bob posts a note that references a third user, also external to Minds, carol@nostr? Should Minds attempt to have a link to that user? But how?
I think this must be solved by either
- Just showing the referenced public key with no link and some special formatting and Alice will figure that out by herself;
- Linking to some external Nostr app that is read-only and only exists to serve as a reference on the open web for browsing Nostr profiles (yet to be build, maybe Minds could build that!);
- If the approach 3 (above) is being used, then the background job would automatically sync also Carol's metadata and store them (temporarily?) on the
nostr_events
table, then they can be linked to and shown to Alice just as Bob's profile is.
The same considerations apply for referenced notes (e.g. if Bob is replying to some other Nostr post).
Comments and replies inside Minds
What happens if alice@minds is subscribed bob@nostr but someone external, say, dan@nostr replies to Bob's posts. Should Alice see Dan's comment? Or maybe Dan is replying to a post by some other Minds user, same problem.
I think these comments and replies should not show up for Alice at all (unless she is also subscribed to Dan). Otherwise this will open a can of spamworms, allowing anyone to create infinite Nostr profiles and have their spam show up inside Minds to Minds' users.
In the future there are a bunch of ways that this can be addressed, but I think it will depend on how the Nostr ecosystem will evolve. My current thoughts on it are that there will be relays that will only accept posts that contain proof-of-work on them, others will only accept posts from paying users or users who pay a one-time anti-sybil fee (like https://expensive-relay.fiatjaf.com/), and relays that will require manual registration etc. Once these things are happening Minds can then pick some external relays that it thinks are doing a good job at preventing spam and only accept Dan's replies/comments if they come from one of these relays (but if Alice has subscribed directly to Dan then it doesn't matter, Dan could be in any relay that Alice should still be able to view his posts, he just won't be spamming the rest of Minds' users).
Another alternative I just thought about that may be doable (but again, in the distant future) is to have Minds-weighted web-of-trust. So if Dan, an external Nostr user, is being followed by a bunch of Minds' users that are known to not be bots, then Dan is automatically considered to be legit too and Dan comments/replies can start showing up for everybody inside Minds.
Thank you for your patience in reading up to this point.