How are you associating the IP with the pubkey? That's the only thing I don't get. Fetching media doesn't reveal the pubkey. Only publishing an event to a relay would. Did you write a strfry policy to do it?
Instead of q tags, just send the event ID to a proprietary cloud service and make it create a screenshot of the post, which you then upload as an image to nostr.build and insert the URL into the content with a giant hash and no imeta tag. Problem solved.
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.
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.
Nips luds nostr lnurl schizophrenia
Mastodon has a pure anarchist philosophy when it comes to decentralization. They think your server should have zero reliance on anything else. Bluesky takes the opposite approach, more like an authoritarian socialist one, where there is an high level of reliance on the official Communist party servers, but the whole stack is made up of user-interchangeable microservices. So for example, as a user you could run a custom timeline algorithm service and other users could point to it. It's basically the Twitter microservices topology but users can set the URLs to each piece. Importantly, identity is centralized on Bluesky's BGS.
Nostr does not take a pure anarchist approach to servers, but it does take a pure anarchist approach to clients. That's how it's different. Although in reality, with many clients relying on services such as nostr.build, and there being many singleton services like Primal or nsecBunker or whatever without the clear message to "host your own" as the main way of doing it, Nostr is a big mixture of everything.
On a protocol level:
Identity - public keys vs URLs
Network topology - clients and relays vs servers
Data format - Nostr events vs ActivityStreams objects
On a people/reality level:
ActivityPub is way larger
Nostr has money built into the tech, and ActivityPub is very resistant to it
Nostr is young, ActivityPub is old and based on something even older
Nostr has jack and snowden. ActivityPub bullied Will Wheaton off the protocol
It does (mostly) blindly relay everything. But this is considered okay because of anti-spam mechanisms on clients, relays, and on ActivityPub servers themselves.
That one annoying user was using a single pubkey and not actually doing anything new or interesting, except that he got an nsec that already had followers. Blocking the pubkey on my server made it stop. He's just a troll, not a hacker.
I'm sorry to inform you that your wife got deprecated.
This time Democrats are going to actually steal the election, but no one will believe it.
If we standardized the URL format it could be swappable by the user. It's so simple anyone could implement it. Less than 200 lines of code.
I built a small media proxy a while back. Clients could host something like this to solve it. https://gitlab.com/soapbox-pub/proxy-worker
Of course. All I'm saying is that if the account says "Pablof7z" and it has Pablo's profile picture, and it's followed by karnage, fiatjaf, and jb55 (just examples), someone might wonder why Pablo is telling a bunch of people to "kill yourself" over and over. It's very clever they used that particular nsec, because the follows do lend it credibility. We need a better way to burn nsecs.
The person above you is bothered that you're still following that particular account, that's the point. It gives credibility to an account when other high profile users still follow it.
It's an account where somebody shared the nsec on purpose as an "experiment", but somebody has been using it to harass people while pretending to be Pablo.
Epic
One of the basics of computers is understanding that like half of all file formats are just zip files with a particular structure. You might be surprised at how many formats you can rename to ".zip" and open it up.
Gangstalked by Duolingo.
The top capacity Lightning node has 20 million dollars in it. https://1ml.com/node/03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f