Avatar
Joel
8ec44004cbe32b091c29d6c3274f481c13b8b6e4d7c9fc0b526d849277494e4d
testing this out
Replying to Avatar Constant

Nostr, where your puritanical attitude towards cryptography dies in the name of dirty disgusting revolting pragmatism and convenience.

Now, I have copy-pasted and cleartext .txt-file stored many bitcoin keys in my days, but nothing as absurd as how I have treated my nsec thus far. There may be a solution that is great, if only we take our sensibilities to a dark alley and shoot it in the face.

FROST is a threshold multi-signature scheme that allows you to take your Nsec, and turn it into a multi-sig where a majority needs to coordinate in order to create a valid signature under your Npub.

Check out a demo here (don’t actually use this): https://join.the-nostr.org/.

It is simple: you put in a nsec, and you get a bunker URL back. Subsequently you can schizo-store the smashed in steel nsec away deep inside the tunnel network underneath your home, and instead copy paste that URL into all those different Nostr clients.

Lost your URL? Or did the service go down? No problem! Just venture back into those tunnels, re-acquire your nsec and create another set-up at another service elsewhere, easy. Did your URL get compromised? Ask the signers to stop cooperating and reset the multi-sig.

Obviously you run the risk that the signers you made part of the multi-signature scheme collude and compromise your secret. But honestly, in a world where you are supposed to keep a secret superduper safe, but also are expected to use it all the time; getting to a point where the ‘keep it superduper safe’ becomes a lot easier because what you ‘use all the time’ is some derivative in a trusted set-up that can be swapped out, might just be an actual step forward.

Ceterum censeo Carthaginem esse delendam.

Good points. I think you're touching on something fundamental, and that is that on Nostr you have to accept that all accounts are throwaway. And act accordingly.

The architecture mandates this. Call it architecture-mandated psychology if you want a fancy phrase. Anyway FROST isn't a solution, it just highlights the problem from another direction.

Sadly, conventional micro-blogging is a bad use case for a world in which all accounts are throwaway. Conventional long-form blogging even worse.

So the biggest problem isn't the architecture. It's the current leading use case.

One thing that nags me testing Nostr out is I can never be sure if I'm seeing all the replies to an interesting post. I've setup a few clients, each with different (but pretty standard) relay setups, some overlapping and some not, and I've been using them to examine popular posts. Each client often presents a separate story of the life of a given post, some replies are here but not there, some are there but not here, some are missing certain types of replies (like quote replies), some aren't, like numbers can jump around a lot, and so on. I also realise there is filtering at the client level too, keeping out replies from new users and such, and that further complicates things. I hear this outbox implementation is slowly being adopted, but I don't think that really solves the problem to anywhere near the degree I would hope, as there are just too many variables at play. Maybe the idea is to just accept that—i.e when it comes to strangers' replies on strangers' posts you'll never really know how much of what you're seeing represents the totality of the story of the post?

Context: I've setup a different mix of popular relays on each to try and simulate the experience of a group of users. But also each client does filtering too, so that adds another "can't be sure" layer.

Test time! I'm going to post this note here on Primal with Relay set A and then use some non-following test accounts to like it in a few other clients with certain other test relay sets, including non-overlapping, and then let's see how many of those likes total up here.

Fair but I think it almost never costs more to censor than to allow. Humans like to be in spaces that other humans, either implicitly or explicitly, aren't allowed to enter. We'll gladly pay for that. And most humans also don't like labour, including the labour of having to create and maintain such spaces themselves (those that do are outliers). Humans love to outsource. Therefore, for an online business, setting rules drives revenue, and even if it costs more in absolute terms to censor this or that, those costs are offset by the gains in revenue from people willing to outsource the labour of curation.

Yeah but businesses have the right not to go out of business, and free speech is, by and large, very bad for business. It's extremely hard to be in favour of the right of individuals to near-total free speech in commercial domains and also the right of businesses to make a profit. You can be in favour of near-total free speech in a charity/NGO/expensively-manifested-thought-experiment domain, that's cool.

Replying to Avatar Hypno Kitty

Except it ain’t so easy to switch to a different BlueSky server. Here’s what ChatGPT says about it:

Migrating your Bluesky account to a different server involves several technical steps:

Account Creation on the New Server: Establish an account on the target Personal Data Server (PDS). This requires proving control over your Decentralized Identifier (DID) by generating a JSON Web Token (JWT) signed with your existing signing key.

GITHUB

Data Migration: Transfer your existing data, including posts and media, to the new server. This process entails exporting your repository as a Content Addressable aRchive (CAR) file and importing it into the new PDS. Additionally, you'll need to upload associated media blobs and migrate private settings like preferences.

GITHUB

Identity Update: Modify your DID document to reflect the new server's details, such as the endpoint and signing key. For DID

users, this involves submitting a signed operation to the PLC directory, which may require email verification and handling of cryptographic keys.

GITHUB

Finalization: Activate your account on the new server and verify the integrity of the migration. It's advisable to deactivate or delete your account on the previous server to prevent conflicts.

GITHUB

Due to the technical nature of these steps and the potential risks—such as data loss or account inaccessibility—it's recommended to proceed with caution and ensure a thorough understanding of the process before initiating a migration.

On ATproto, if self-hosting you wouldn't actually need to do that though, unless moving cloud providers or if your bare metal server died and you want to restore to a new one. The same PDS works for multiple Appviews (clients), so no need to move anything. Just that right now there is really only one Appview.

Thing is most people run everything through a subconscious "How does this affect my food supply?" filter. Someone in 1950s America might be mortified if a nude photo of them was passed around the office, whereas someone from some remote tribe somewhere would have no issue with everyone in their world having seen them naked. Why is one mortified and one not? Because to be exposed in the first instance is to be socially looked down upon, and our brands are hard-wired to interpret being socially looked down upon as a risk of diminished food supply (red alert). Other words, all comes down to food.