diff options
author | terminaldweller <devi@terminaldweller.com> | 2024-03-05 19:25:48 +0000 |
---|---|---|
committer | terminaldweller <devi@terminaldweller.com> | 2024-03-05 19:25:48 +0000 |
commit | ce567a174835644d29f3b7f4a4626f07dfb05b0a (patch) | |
tree | 4ade54ab126046515fda0dc959f6d40bbaa71607 /mds/oneclientforeverything.txt | |
parent | downgraded mongo to v6 for now (diff) | |
download | blog-ce567a174835644d29f3b7f4a4626f07dfb05b0a.tar.gz blog-ce567a174835644d29f3b7f4a4626f07dfb05b0a.zip |
added a new script to conevrt all md to asciidoc, rss feed now sends the entire asciidoc for the teaser
Diffstat (limited to 'mds/oneclientforeverything.txt')
-rw-r--r-- | mds/oneclientforeverything.txt | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/mds/oneclientforeverything.txt b/mds/oneclientforeverything.txt new file mode 100644 index 0000000..9d61a5b --- /dev/null +++ b/mds/oneclientforeverything.txt @@ -0,0 +1,253 @@ +== One Client for Everything + +== Table of Contents + +[arabic] +. link:#foreword[Foreword] +. link:#two-ways-of-solving-this[Two ways of solving this] +. link:#the-web-app-way[The web app way] +. link:#gui-or-terminal-client[gui or terminal client] +. link:#matrix-or-irc[Matrix or IRC] + +=== Foreword + +First let’s talk about the problem we’re trying to solve here. I want to +have a unified interface into all the communication forms that I use. I +can’t be bothered to have different clients open all the time. I want to +have one client that takes care of all things mostly well. + +=== Two ways of solving this + +There is generally two ways one can try to solve this. Number one is to +just use a browser. Almost all forms of comm nowadays have a web client +so basically one way of solving our problem is to a dedicated browser +that has all the clients open. Mind you, there are even specialized and +more lightweight browser offerings specifically geared towards this +use-case but still this option is not ideal in terms of resources and +the interface you’re getting is not really unified. + +==== The web app way + +An example that comes to mind for this sort of solution is `rambox` +though they are no longer offering a FOSS solution. I’m just mentioning +them as an example of what’s being offered out there as a ready-to-use +solution. + +Although this way of doing things is very resource-intensive, this is +the *complete* way of doing things. What I mean by that is that by using +the official web apps, you will not be compromising on any features that +the clients offer since you will be using the official clients. + +==== gui or terminal client + +The second way of going about and solving this is to pick a very good +client that supports a protocol with a lot of bridges and then bridge +everything through to the app of that one protocol. Currently there are +only three protocols that have enough facilities for bridging to make +this feasible. IRC, Matrix and XMPP. I’m adding XMPP for the sake of +completion but in terms of practicality XMPP doesn’t have nearly as many +bridges as IRC and Matrix. + +So this basically narrows down our choice to either IRC or Matrix. Now +lets look at the clients that are available for these two protocols. + +==== Matrix or IRC + +The last requirement on my side is that i would rather use a unified +terminal keyboard-based client than a web application client. That being +said, i definitely expect to use a web client since using a terminal +client on a smart phone is pretty much just pain. A lot of pain. + +Unfortunately at the time of writing this post, Matrix has no terminal +client that comes close to either https://github.com/irssi/irssi[irssi] +or https://github.com/weechat/weechat[weechat], both terminal clients +originally only supporting IRC but later advertising themselves as +multi-chat clients. Also as an added bonus, starting from the next irssi +release which should be irssi v1.5 one can elect not to build the IRC +module at all while building irssi. + +Matrix and IRC both have a rich ecosystem of bridges. Matrix has a +growing fan base which means more and more bridges or tools with similar +functionality will be releases for it. Contrast that with IRC where that +number seems to be smaller than Matrix but still is very much alive and +well. + +=== https://github.com/bitlbee/bitlbee[bitlbee-libpurple] + +.... +it'll be bitlbee +.... + +bitlbee is a bridge software for IRC. The distinguishing feature for +bitlbee is that the way it bridges other protocols to IRC is by +masquerading as an ircd. You could also use libpurple as the backend for +bitlbee (https://wiki.bitlbee.org/HowtoPurple[link]). libpurple has an +origin story similar to libreadline. Basically it used to live inside +pidgin, but later on it was turned into a library so that other +applications could use it as well. + +List of protocols supported by libpurple: + +.... +aim +bitlbee-discord +bitlbee-mastodon +bonjour +eionrobb-icyque +eionrobb-mattermost +eionrobb-rocketchat +facebook +gg +hangouts +hehoe-signald +hehoe-whatsmeow +icq +irc +jabber +matrix +meanwhile +novell +otr +simple +sipe +skypeweb +slack +steam +telegram-tdlib +zephyr +.... + +=== https://github.com/42wim/matterbridge[matterbridge] + +matterbridge is an everything-to-everything bridge. + +Please keep in mind that with matterbridge, you don’t get the full +functionality of a protocol as in you get no private messages and such. +You get the ability to join public chat rooms or whatever they call it +in that protocol. + +=== bridge ircds + +==== https://github.com/42wim/matterircd[matterircd] + +a mattermost bridge that emulates an ircd as the name implies. + +==== https://github.com/progval/matrix2051[matrix2051] + +another bridge that emulates an ircd, but for matrix. + +==== https://github.com/adsr/irslackd[irslackd] + +a bridge to slack that emulates an ircd. + +==== docker compose + +https://github.com/ezkrg/docker-bitlbee-libpurple[Here]’s the original +Dockerfile. You can find mine +https://github.com/terminaldweller/docker-bitlbee-libpurple[here]. And +here’s the docker compose file I use that goes with that: + +[source,yaml] +---- +version: "3.8" +services: + bitlbee: + image: devi_bitlbee + deploy: + resources: + limits: + memory: 384M + logging: + driver: "json-file" + options: + max-size: "100m" + networks: + - bitlbeenet + ports: + - "127.0.0.1:8667:6667" + - "172.17.0.1:8667:6667" + restart: unless-stopped + user: "bitlbee:bitlbee" + command: + [ + "/usr/sbin/bitlbee", + "-F", + "-n", + "-u", + "bitlbee", + "-c", + "/var/lib/bitlbee/bitlbee.conf", + "-d", + "/var/lib/bitlbee", + ] + dns: + - 9.9.9.9 + volumes: + - ./conf/bitlbee.conf:/var/lib/bitlbee/bitlbee.conf:ro + - userdata:/var/lib/bitlbee + - /home/devi/.cache/docker-bitlbee/signald/run:/var/run/signald + - /etc/ssl/certs:/etc/ssl/certs:ro + signald: + image: signald/signald:stable + deploy: + resources: + limits: + memory: 384M + logging: + driver: "json-file" + options: + max-size: "100m" + networks: + - signalnet + ports: + - "127.0.0.1:7775:7775" + - "172.17.0.1:7775:7775" + restart: unless-stopped + dns: + - 9.9.9.9 + volumes: + - /home/devi/.cache/docker-bitlbee/signald/run:/signald + - /etc/ssl/certs:/etc/ssl/certs:ro + environment: + - SIGNALD_ENABLE_METRICS=false + - SIGNALD_HTTP_LOGGING=true + - SIGNALD_VERBOSE_LOGGING=true + - SIGNALD_METRICS_PORT=7775 + - SIGNALD_LOG_DB_TRANSACTIONS=true + matterircd: + image: 42wim/matterircd:latest + deploy: + resources: + limits: + memory: 384M + logging: + driver: "json-file" + options: + max-size: "100m" + networks: + - matterircdnet + ports: + - "127.0.0.1:7667:7667" + - "172.17.0.1:7667:7667" + dns: + - 9.9.9.9 + restart: unless-stopped + command: ["--conf", "/matterircd.toml"] + volumes: + - ./matterircd.toml:/matterircd.toml:ro +networks: + bitlbeenet: + signalnet: + matterircdnet: +volumes: + userdata: + matterircddb: +---- + +timestamp:1699398469 + +version:0.1.0 + +https://blog.terminaldweller.com/rss/feed + +https://raw.githubusercontent.com/terminaldweller/blog/main/mds/oneclientforeverything.md |