Global namespace extremist. Defragment your communities!

  • 0 Posts
  • 25 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle
  • I host 2 ejabberd servers. One casual, federated, the other one standalone, for work.

    • Conversations is a decent android client that supports modern XMPP standards
    • Dino on the desktop. It just happen to support the same subset of standards as Conversations, so they work pretty well together.

    For Mastodon, I’m using an Akkoma instance hosted by a frind of mine

    • Tusky works pretty well with it. There were certain annoying bugs when I combined the official Mastodon app with Akkoma.

    Every once in a while I try Matrix, but each time I try to log in, Synapse is is fucked in a different way. I have to scrap it up and start from the ground up some day.

    • Only the element based clients so far, because every alternative lack certain features.

    I’m a big fan of Nostr, because of one particular feature - You control your identity without having to selfhost a server. The network seems to be occupied by the christian-carnivore-bitcoin-conservatives so far, therefor it’s pretty bland when it comes to content.

    • Amethyst on Android
    • Gossip on the desktop. This one requires a certain knowledge of the protocol. Each action needs to be manually triggered.

    For some special use cases I have Signal, but most of the time, Telegram is the best the average person can do to meet me in the middle.





  • Gmail offers imap amd smtp access. You have to enable 2FA, and then it will allow you to create account for so called “less secure apps”.

    In your place, I’d either continue using gmail directly, or finish the configuration of the self hosted mail server and just use that with any smtp/imap client. I suggest getting a separate domain for testing first, before moving your primary inbox there.



  • you still need good security configuration of the exposed service.

    In a sense that security comes in layers, yes. But in practice, this setup will prevent 100% of bots scanning the internet for exposed services, and absolute majority of possible targeted attacks as well. It’s like using any other 3rd party VPN, except there’s not a central point for the traffic to flow through.

    From the attackers point of view, nothing is listening there.

    I’ve used a similar setup in the past to access a device behind a NAT (possibly multiple NATs) and a dynamic IPv4. Looking back, that ISP was a pure nightmare.












  • Of course security comes with layers, and if you’re not comfortable hosting services publically, use a VPN.

    However, 3 simple rules go a long way:

    1. Treat any machine or service on a local network as if they were publically accesible. That will prevent you from accidentally leaving the auth off, or leaving the weak/default passwords in place.

    2. Install services in a way that they are easy to patch. For example, prefer phpmyadmin from debian repo instead of just copy pasting the latest official release in the www folder. If you absolutely need the latest release, try a container maintained by a reasonable adult. (No offense to the handful of kids I’ve known providing a solid code, knowledge and bugreports for the general public!)

    3. Use unattended-upgrades, or an alternative auto update mechanism on rhel based distros, if you don’t want to become a fulltime sysadmin. The increased security is absolutely worth the very occasional breakage.

    4. You and your hardware are your worst enemies. There are tons of giudes on what a proper backup should look like, but don’t let that discourage you. Some backup is always better than NO backup. Even if it’s just a copy of critical files on an external usb drive. You can always go crazy later, and use snapshotting abilities of your filesystem (btrfs, zfs), build a separate backupserver, move it to a different physical location… sky really is the limit here.