- The web hosting is in the cloud, but if it's easy to change it, what's the problem?

- Git a url and you can easily change the central backup server point.

As for the cloud there are loads of clouds. Web sites can be moved. Same with git hosting which just provides a convenient place to store the repo and post meta data like issues. Moving from GitHub to Gitea or GitLab is usually pretty easy.

More and more people seem to be at least trying a less centralized approach. Personally I think we passed peak centralization in the middle 20-teens when there were just a few social platforms everyone used and federated stuff was primitive and new. We are well into the beginning of the unbundling phase.

Nowadays if I need to spin up a chat with people I know I just give them a shell function that utilizes a self-hosted instance of devzat.

    # uncensored chat using self hosted https://github.com/quackduck/devzat.git
    # add to .bashrc or /etc/profile.d/functions.sh on a VM somewhere
    function chat()
    {
    # make us a temporary nickname
    Name=$(base64 /dev/urandom | tr -d '/+' | dd bs=12 count=1 2>/dev/null)
    # make us a temporary throw away ssh key.  key is our ID.
    ssh-keygen -q -t rsa -b 2048 -N "" -C "${Name}" -f ~/.ssh/.chat_"${Name}"
    # add +ssh-rsa in the event client restricts weaker ciphers
    ssh -i ~/.ssh/.chat_"${Name}" -p 22 -4 -o "HostkeyAlgorithms +ssh-rsa" -o "PubkeyAcceptedKeyTypes +ssh-rsa" "${Name}"@23.239.0.70
    rm -vf ~/.ssh/.chat_"${Name}" ~/.ssh/.chat_"${Name}".pub
    }

anyone in IRC chat can still record everything just fine

I addressed this. Yes, someone can invite a bot in a channel they control and the channel operators can kick/ban a bot. Also people can achieve E2EE encryption using OTR. So in fact there are two layers of encryption, one of which individuals control and the IRC admin has no visibility into. There is an unsupported OTR custom client for Discord but it is against the terms of service.

Discord on the other hand has visibility into everything and no way for users to know this. Anything said on Discord in text or voice is a permanent transcription record. People are made to believe they can delete messages, but they are just flagged as deleted in Cassandra.

If I want a private voice conversation with someone or a group, I invite them to my private uMurmur server. There are clients for workstations and cell phones. Some people won't use such things and those are not people I would likely ever talk to anyway.

Transit encryption maybe, but admins can still read everything.

Devzat supports a "private" mode in which only some IDs you specify in the config file are allowed to join. In that mode, it disables the 16 message backlog on #main too. It seems like that would be a good option for you, but it looks like you're having the people you know gen new SSH keys every time (which is what IDs are based on). I'm curious why.

Would you have liked a standalone preference for whether to have a backlog? What features would you like / what things could be improved?

Always interesting to see how devzat is being used.

This is just an example of an ephemeral implementation of your chat system. Spin up a node, have some people play around with it, communicate whatever they wish then destroy the node in the sense of destroying a VM. One could certainly leave it running and people could use persistent ssh keys like you do on your instance. Using ephemeral ssh keys implies more aspect of anonymity assuming one connects from a short-lived VM. People could of course adjust my example shell function to not remove keys and to use a persistent nick-name.

Would you have liked a standalone preference for whether to have a backlog?

That sounds like a great feature/configuration option. Maybe even allow a admin-defined backlog size for people that want persistent instances.

What features would you like / what things could be improved?

I think it is great as-is but that is just my personal take. For me, simpler is better. I appreciate that you added a configuration to disable external integrations. Less specific to devzat but more specific to golang would be to have default compile-time hardening options. I am impressed with how nice you made it look with the color schemes.

Perhaps others here will play around with it and offer suggestions. SSH based chat is not super popular which really surprises me. I could see devzat being an amazing fall-back for a private chat inside a company when Slack or Discord are having a moment or for those times when people want to say something that isn't recorded forever and especially not visible to their management.

Done! https://github.com/quackduck/devzat/commit/00160b83751d90176...

> SSH based chat is not super popular which really surprises me. I could see devzat being an amazing fall-back for a private chat inside a company when Slack or Discord are having a moment or for those times when people want to say something that isn't recorded forever and especially not visible to their management. I think it would also be amazing for people in oppressive regimes that block access to all the mainstream chat platforms but allow SSH to specific VPS providers.

:))))) I'm glad you like devzat. I'd love to talk to you on the main chat!

"The internet" - the corporate internet. "The internet" - normal people on the internet. "The internet" - etc.

People moved off of IRC because it was inconvenient for less-technical users, it is far easier to just download an app. That doesn't mean they want those apps to be centralized, or don't want their social media to be fragmented so they're talking to only like-minded individuals.

It is 100% possible that someone creates a technologically-centralized app that allows for a decentralized audience and moderation. I'm not aware of anyone doing this though.

There's also Reddit (to an extent)

No it isn't. Look at all the things https://discord.com/guidelines and https://slack.com/acceptable-use-policy say you can't do. For example, Discord bans sharing cheats for even single-player games, and Slack bans discussing ideas for a chat app of your own.