So, I've been studying #Mostr, and I think it's bad for #Nostr. Nothing against the Fediverse, I just don't think it follows the right philosophy. Normalizing it is a threat to sovereignty. Personally, I recommend muting all Mostr NIP-05s.

I am not calling for Mostr's destruction, but perhaps tools for clients and relays to mitigate custodial account services like Mostr. A single service shouldn't dominate the timeline the way it does, unless the user wants it to.

Let's also face the basic truth: Not your keys, not your account. Mostr holds all the nsecs. They are generated like this:

=====

/** Generate Nostr keys from a seed. */

async function generateKeys(seed: string) {

const privateKeyBuff = await getDigest(seed);

const privateKey = secp.utils.bytesToHex(new Uint8Array(privateKeyBuff));

return {

privateKey,

publicKey: secp.utils.bytesToHex(secp.schnorr.getPublicKey(privateKey)),

};

}

/** Get Nostr keys for an ActivityPub ID. */

function getActorKeys(apId: string) {

return generateKeys(Conf.secretKey + ':' + apId);

}

=====

Where "Conf.secretKey" is a seed value generated with "openssl rand -base64 48".

This is definitely a secure way to make nsecs, but it also secures every account with the same private key. Were that key to be compromised, it's a single-point-of-failure. A staggering number of trusted accounts could be botted in an instant.

That key is stored in plaintext inside of a "config.ts" file on the Mostr server, so we're really just one zero-day away from an issue. We really shouldn't trust accounts like these by default.

Even if nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 is the most trustworthy person in the world, letting one person own that many trusted nsecs is a bad idea. I'll keep repeating this term till it sticks: ZERO-TRUST.

Also, while I respect Mostr being an open-source project, that in itself is a threat given what Mostr does. Standing up your own Mostr is trivial, but could you imagine two Mostrs? That's immediately a spam problem, and probably in invitation to cause a loop to form somewhere. Imagine 10 Mostrs; complete chaos. Nothing is preventing this.

And, just a petty complaint, but everyone on Nostr identifies themselves by npub, but on the ActivityPub side of Mostr, Nostr users are identified by hex pubkey. Fixing this now is basically impossible, and it hurts user-friendliness. That's not our problem though.

Reply to this note

Please Login to reply.

Discussion

That said, a fediverse/nostr bridge could be realized on a per-instance basis eliminating the single-point-of-failure, but increasing the attack surface by adding custodial keys to multiple instances.

I can't think of a sustainable way do make it non-custodial on a per-user basis that isn't just a crossposter.

Interesting. Having a bridge is valuable, but you make a good point. I suppose the main point being that Alex only owns any given person's "ActivityPub account bridged via my Mostr instance", not that person's nostr-native identity. So maybe mostr accounts could be shown, but a warning included that it's equivalent to bridged RSS feed or Twitter account. This MITM type attack can happen with any bridged content; there's no trust profile at all.

ActivityPub is built on trust, so the fact that Nostr users trust me is not fundamentally different than Nostr users trusting any ActivityPub server. It's a flaw of ActivityPub. Good design leans into both strengths and weaknesses of a system.

I have a track record of being a trustworthy person. The risk here is losing the key, which can happen by mistake. It's not a sustainable long-term solution. I am aware of that fact, and so are many others. It's a short term solution to enable collaboration across protocols.

Having multiple bridges would not be as bad as you think. It publishes events with NIP-48 proxy tags: https://github.com/nostr-protocol/nips/blob/master/48.md And bridge servers ignore any events with this tag to prevent duplication and loops.

Clients would have to use proxy tags to deduplicate content if there were multiple bridges. And I am currently building a client specifically to do that (among other things): https://gitlab.com/soapbox-pub/ditto

You can check my slide show about Mostr if you want to know about the bigger vision: https://poast.tv/w/jUknj6g3BbkESsidKbDRzr

Thanks for taking a look.

This is pure mostrphobia 😤

😭

Jk jk

I do wonder how much of Nostr's daily active user stats are made up of mostr users? (I'm assuming it counts then)

Completely agree with you on this. I removed the mostr.pub relay because there’s nothing worth seeing on there that I felt I was missing.

I deleted my first Mastodon account and only created another one just to ask Mullvad if they had any plans to join the #Nostr. (They don’t.)

Users should also avoid any client that custodies and doesn’t let users access their nsec, such as nostr:npub1earna05hx6ax38r33h3atmecjzdu547m8suw87w70aw6mlyga4hsqcja5j. That’s bad news in my book.