Slidge - XMPP gateways - 2025-02-21

> hmmm maybe Peter, but re-reading what deuill wrote I actually think the community itself is useless and the "announcement" group is a different group anyway Yeah the Community group itself is useless AFAICT ↺

What extra data do you need to store for it? Is is not possible to just *not* call `add_to_bookmarks()` on it?

It's interesting that WhatsApp implemented this similarly to Matrix, where the "space" is also a weird channel with no activity, just a "parent" for the groups inside it

> yeah, the spaces space in XMPP is sadly a bit short on people actually proposing something concrete I guess what is needed for slidge could be a starting point. We could start without management/moderation of the "space", but a read-only thing. At a high-level, the way I see it: - a disco#info item on the MUC meaning "I belong to space 'ID-OF-A-SPACE' name 'SOME-NAME' " - a disco#feature on the component meaning "I support spaces" - a handler for iq/get/spaces that returns the list of spaces - a handler for iq/get/space/ID-of-a-space that returns the list of MUCs belonging to this space …and that's it? I mean that's it, except client support lol ↺

nicoco: I'd argue in favor of not binding the space to a muc component. Maybe not using the word in the spec is enough, just listing requirements that the entity should support for spaces to work.

pep., because you're thinking of "multi-server" space, right?

I'm concerned that trying to come up with the perfect federated solution is what actually prevents spaces from becoming a thing…

And maybe it's fine if we start with a "single muc component"-spaces spec? For sure this is all we need for slidge… I'd like to avoid trying to spec something I'll never implement and have no experience with :/

> pep., because you're thinking of "multi-server" space, right? Yes. Tbh sometimes it's really not harder than removing some constraints that have been put there for weird reasons ↺

helooo. I'm getting a "no commands available" error when i try to register using slidgram I installed it through pipx and i'm running this command `doas slidge --legacy-module slidgram -j slidgram.sillybiz.xyz --secret SECRET` in my prosody configuration i added ``` Component "slidgram.sillybiz.xyz" component_secret = "SECRET" -- replace this with a real secret! modules_enabled = {"privilege"} -- optional, additional config required to make it work VirtualHost "sillybiz.xyz" privileged_entities = { ["slidgram.sillybiz.xyz"] = { roster = "both"; message = "outgoing"; iq = { ["http://jabber.org/protocol/pubsub"] = "both"; ["http://jabber.org/protocol/pubsub#owner"] = "set"; }; } } ```

I use the debian package instead and it seems to work perfectly

so um, never mind!

vess: looked like a user-jid-validator issue but I don't see why the debian package would fix it though

nicoco: slidge Magic 🪄✨

nicoco: btw .. how far is my FR?

> nicoco: I'd argue in favor of not binding the space to a muc component. Maybe not using the word in the spec is enough, just listing requirements that the entity should support for spaces to work. bind it to what then? how would you fetch the list of MUCs? ↺

I'm assuming i misconfigured something and the debian package has things correctly preconfigured (i nuked all of my configuration and used the configuration files from the debian package :p)

cool! this debian package often is trouble, it's cool if it worked nice for you :)

I mean it should work but I don't use it myself so sometimes I break it unvoluntarily :)

i'm actually having a little problem now... i logged into the telegram account but it doesn't seem to be sending or recieving any messages...

contacts synced fine

pep. also, the "space" itself could be in a MUC component, but still list groups from other servers? ofc for federated management of members/roles/whatever, this would require some more protocol, but I feel like everything has been stalled for so long because we're looking for the perfect federated solution that covers all use cases. it seems like starting with something is better than having nothing at all.

vess: well, `sudo journalctl -u slidge@telegram` may give an indication as to what is happening then

looking at that rn, nothing, i'll change the log level

strange!! only that one contact seems to be bugged

i added a new contact and it works perfectly

the logs say it just ignores those messages

anyway, thanks!!

> strange!! only that one contact seems to be bugged well that is interesting and probably worth investigating, if you could anonymize and share the logs that says it ignores the messages from/to this contact I would be happy to have a look and fix this ↺

i fixed it by asking the person i was messaging to make their number public on telegram, add them, then make the number private

oh, that is interesting

>> nicoco: I'd argue in favor of not binding the space to a muc component. Maybe not using the word in the spec is enough, just listing requirements that the entity should support for spaces to work. > bind it to what then? how would you fetch the list of MUCs? You can say that disco#items on the entity returns the list of mucs on the space. You don't have to say it's a muc component :) ↺

oh right ok

pep., what's the benefit of disco things over adhoc? I basically implemented "read-only" spaces for discord, matrix and mattermost already, as adhoc commands. Don't you think it actually makes more sense to submit a spec for something already implemented?

if clients want to implement a better UI, they can, if not, it works (without great UX, but works) in XEP-0050-supporting clients?

Yes the point is to have something you disco#items on to get the list of items. If the thing is a domain jid and local parts on it are usually MUCs we say "MUC service" but that's not what's important for spaces per se

Though I would default to doing both of those things in most cases

Hello everyone, long message ahead, sorry if this isn't the right place. I'm a hobbyist running my own Ejabberd server on FreeBSD, and was wondering if I could get some help or pointers on getting slidge to work. I realize neither Ejabberd nor FreeBSD are officially supported, but I do know my way around Linux/Unix and think I could get them running with some help, and maybe even help supporting and documenting them. As there's no proper Docker on FreeBSD (and I don't really like Docker anyway) I opted for pipx, and installing slidge-whatsapp through there results in an error (I can share the log if you want). Could somebody perhaps guide me through compiling and setting up everything needed to get slidge-whatsapp running manually? FreeBSD offers the _purple-gowhatsapp_ package which includes _libwhatsmeow.so_ if that's any help. ✏

gal: this is the right place for support, but I have to AFK right now unfortunately. some people here have slidge running on BSD something, it should work

Hey no worries! Anyone with some valuable input that can help me set it up, you'd put an end to all my grief (dependency on Whatsapp) and I'd be eternally greatful (:

podman works on FreeBSD and can run Linux OCI images. Not officially supported, but I've successfully tested an alpine image on it

The thing is I've got Ejabberd running on a simple $5 VPS with little ram and processing power, so I don't really want to employ any kind of virtualization. Is there no officially supported (or encouraged) way of downloading the code, compiling it, and running it natively?

You can install using pipx, as mentioned in the READMEs of various slidges It works for me on OpenBSD. Not sure about FreeBSD though

Something like: ``` pipx install slidge-whatsapp==0.0.0.dev0 \ --pip-args='--extra-index-url https://codeberg.org/api/packages/slidge/pypi/simple/' ```

(I did not try slidge-whatsapp, but slidgram and slidcord worked for me on OpenBSD)

> I mean it should work but I don't use it myself so sometimes I break it unvoluntarily :) lyer ↺

jails/docker aren't virtualization, they use the same kernel as the underlying system. They're more like a fancy chroot

If it works on OpenBSD, it'll probably work on FreeBSD though :)

Well pipx as I've mentioned fails for me with slidge-whatsapp. If anybody wants I can share the error it produces. I think it's something to do with some go-python interfacing library. That's why I wanted to know if there's a way for me to manually compile it and set it up without pipx, so I can maybe get a better idea of why it fails.

gal: do you have a go compiler installed?

Yeah, the _go_ package offered by FreeBSD

You could clone the repo and run `gopy build` in the `slidge_whatsapp` directory.

nicoco: Hi. Smth new on board the WA-slidge? This is my first time to get this error and what is most interesting that it came in my local language 😃 ↓ `SIMS(image/png, 690523B, требует совместимого клиента)` _SIMS demands compatible client_ I sometimes send screenshots in PNG from Psi+ and up today I've found the upload_link to a file in my Conversations App, but tonight…

> You could clone the repo and run `gopy build` in the `slidge_whatsapp` directory. deuill: Exactly what I was looking for, thanks! I'll see how far I can go with it tomorrow

Sounds like a client-side error

Sending client or Receiving (Whatsapp) one?

Sounds like a PSI+ error