• 0 Posts
  • 24 Comments
Joined 7 months ago
cake
Cake day: June 4th, 2025

help-circle
  • The general process would look something like:

    1. Find all of the SSH keys you want to replace.
    2. For each of thise keys, identify everywhere you use it to authenticate, and write this down! This list will form the basis of the rest of the plan. Make sure you list all of the accounts/servers you log in to, and don’t forget things like github or other external systems if you use them.

    You’ll need to perform the following steps for each SSH key you are replacing:

    1. Rename the public and private keys to something like old_id_rsa and old_id_rsa.pub (obviously use the same type name as your key, just prefix old_)
    2. In your ~/.ssh/config, add a line telling SSH to use the old key as well as the new ones: IdentityFile ~/.ssh/old_id_rsa (change the key filename as aporopriate)
    3. Check you can still log in to the servers you could log in to before. It should still be using the old key, just with a different filename, so it should still work.
    4. Generate your new SSH keys ssh-keygen -t ed25519
    5. Log in to each server and ADD the new ~/.ssh/id_ed25519.pub key to the authorized_keys file or equivalent mechanism. Do not remove the old public key yet.
    6. Remove the IdentityFile line from your ~/.ssh/config
    7. Check you can log in to all your systems. This will validate that your new key is working.
    8. Remove your old public key from the authorized_keys file on each server you log in to.

    Depending on your threat model you’re going to want to do this more or less often, and so you may want to consider automating it with sonething like ansible if it’ll be a regular job.









  • I like what you’ve done so far. It’s quick and simple to use. The one bugbear I’ve come across so far is it converting tables to html, rather than storing them as proper markdown.

    I read the reasoning in the documentation, and certainly for my usecases, maintaining it as markdown is more important than trying to perfectly preserve the visual formating, especially as I use multiple devices with different sized screens, so I need different fornatting on each! That’s one of markdowns main strengths, it doesn’t preserve formatting so you don’t need to think about it and it’ll be displayed in a reasonable manner anywhere.

    Is there any reasonable chance that there could be an option, at the server level rather than per page, to store tables as markdown?


  • Community block lists or bans are handled at the protocol level (I think this is task that did that), and are pretty simple, in that they just tell a server not to let a particular user comment or post on a particular community. Thats straightforward enough, and as long as the user’s server obeys that, the user doesn’t get to post.

    Trying to do something similar for every user becomes much more complex as it requires coordinating each user’s settings to all the relevant servers every time they change. It also leaves open the issue of what happens if a user you’ce blocked simply posts a sibling comment to yours, as you won’t see it, but the rest of the community will.

    Personally, I would like to see invite only communities where posts and comments are public (it’s activitypub, so there’s no huding them), but only whitelisted users can post. I know there’s a WomensOnly community here that has a hard time stopping men wading in (I’m guilty if that, I saw an interesting postvand didn’t notice the community name, but the mods were very nice about it). I’m sure they’d like a way of vetting first time posters and commenters.


  • All credit to you for advocating for needs of marginalized groups for protected spaces to communicate, but the fediverse simply isn’t the right tool for that. It’s entire philosophy, design and implementation is centered around making everything public, from posts and comments to votes and moderation actions.

    Asking the fediverse, or the activitypub protocol to allow blocking a user from responding at all is rather like asking a car to be a bike. It’s just not what it is. I can’t really concieve any way of making a decentralized public forum work like that as there is no central point that can control permissions. It might be possible to design a system where communities can control membership and posting priviledges, but even then, if it’s distributed, it would take very little for a hostile instance to simply ignore any central control and display its users posts locally, leading to the same effect as if you just mute them, leaving them visible to others, albiet only on their instance or others that cooperate with it.

    I think that those who are in need of a controlled system should probably be looking at a centralized system that is run and controlled by someone, or a group, that they trust. That would give them the best chance to keep discussions private, and access to read or post controlled. Read access would need to be controlled too, or their discussions can just be mirrored to a hostile server and harassment can occur there where the poster is unaware, just as if they’d muted them.


  • Bear in mind that evrrything you do or say on the fediverse is public, so there is no possible way to stop someone seeing it. Likewise, because the entire system is federated, there is no way to stop an individual from replying to you. Even if the community server rejected their message their own server would be able to display it.

    This works well for general discussions, but I can see where it isn’t ideal for more sensitive topics. People having those sorts of discussions should probably be using a system that is better suited to their needs.









  • Surgery, especially on animals.

    In any other context, someone cutting you open, slicing bits out or rearranging them, them sewing you shut would be considered horrific, but we do it because we know that the short term suffering out weighs the long term harm of not doing it. When you choose it for yourself it might not be too ‘evil’, but an animal would not understand, even if you know it will mean they get to live a long, happy life, free of the pain and suffering that issue would otherwise cause.