XSF Discussion - 2020-01-31

https://github.com/xsf/memberbot \o/ (Thanks MattJ)

Now the question is who gets access to it

Alex at least(?)

I mean, "The Secretary"

And ..

someone who is better at python than I am to help reviweing PRs ;-)

Reviewing doesn't require any special privileges, does it?

I’ll "watch" that repository and see what I can do

Same

Link Mauve, ^

Yeah, I'm going to leave it read-only until someone needs to modify it

https://xmpp.org/extensions/xep-0121.html TIL

"Dublin Core Infobits Mapping"

TIL: pidgin understands OOB, to the extent that it marks the entire body as link (probably to the OOB’d URL)

Hi, is there currently a way to implement puppet bridging for MUCs? Like if I have a public MUC and want to bridge it to some other service and wan't all users from the other service appear to be own MUC users.... (I know about the component way and writing a own MUC service, but that doesn't fullfill my usecase really and is much work to implement)

Is the other service XMPP too?

MattJ, nope in the specific case it's Telegram.... but it should be exchangeable

I think there was a bridge for that

I think matterbridge supports it?

MattJ, I know there is Matterbridge.... I host it myself.... but Matterbridge does no puppet bridging.....

Feature request then :)

MattJ, I did.... but that's why I'm asking how you could implement this in XMPP.....

Not sure what "this" is

Puppet bridging.... so every user from the other platform is a own user in the muc

Sure

Usually in XMPP (which has had bridges, aka transports, aka gateways, for 20 years) a bridge is a component, it can act as any user it wants (on a given domain)

It sounds like matterbridge connects as a client, and not a component, so is limited to just one JID

One thing tho, all the puppets each receive a copy of every message, which might be annoying, but easy to ignore.

Even then it could use multiple resources, but that would require multiple connections to the server which would be icky

Yeah I also thought about ressources and yes this is not that nice.....

And yes Matterbridge acts as a client because the use case is more like you want to bridge existing MUCs.....

There's nothing to stop you doing that

What dou you mean with 'that'?

Bridging to existing MUCs

j.r: https://github.com/moparisthebest/xmpp-ircd works like that (it's a component, each IRC user is a unique muc member)

Nice

MattJ, but that does not seem to be possible with components.... so I have it needs to be done the hacky resource way?

moparisthebest, I'll have a look

j.r, I just said, it's possible with components

Anything is possible with components

xD

A component could act as a MUC service, or it could act as a bunch of clients, it's up to the software

Yeah I'll give it a try

MattJ: larma has a draft xep locally to have bots add information to that would allow clients to know from which participants what message came. that would allow for better display

Bot hats?

that's interesting

Wait, what?

the security considerations on that xep also have to be extremely interesting (by the way everyone I'm actually pep.) (see? >:))

Wait, not just the nickname XEP?

Zash, I guess so a single user could "be" multiple nicknames?

https://xmpp.org/extensions/xep-0172.xml ?

Like in Example 4

oh yea, I vaguely remember Conversations having a bug there

Tho if you have some marker (a Hat!) that says "this is a bridge bot, it's allowed to pretend to be other users" then that'll work

moparisthebest, as far as I understand the components way of xmppircd has still the problem that you need to have multiple connections to the muc service right?

Why do you think that?

Components don't have connections to MUCs at all, they have one connection to their host server, which handles all routing and such for them.

Zash, oh no I though wron xD It's just on s2s to the muc service.....

j.r, nope, so a component is a domain, say something.example.org, it can do anything a domain in XMPP can do, so send messages from user1@something.example.org and user2@something.example.org etc etc

so your component just has the 1 connection to your XMPP server

which then may have various s2s connections and so forth

moparisthebest, and the xmpp server has one connection to the muc server now i understand

unless it is the muc server and then none, but, yes :)

So Components are middle ground between simple client connections and s2s connections.

Zash, yeah I understoof components but not how moparisthebest used them

a bot that can use multiple nicknames in a muc though... duplicates might be rough, and I guess message with nickname wouldn't be enough Zash , because you'd want it to populate the members list?

Myeah

Something like the nickname thing would still be a step up for such bridge bots

what stops them from just being a component though?

Lack of privileges or API capabilities.

Never seen that kind of bot in XMPP actually, only in other things.

which kind?

The kind that post messages from The Other Side with text like "$user: $message" or somesuch.

ugh

Last such I saw was a Matrix bridge on Gitter

And waaaaaay back the Skype bot we had worked like that on the Skype side because there's no proper API for Skype, but on the XMPP side it was "puppets", ie looked like normal MUC participants.

I've seen an XMPP bridge bot :)

I don't remember if that's because I wrote it or not.

rather than solve the specific MUC case, you could have a "I'm connecting like a client but actually want an entire domain and to operate like a component" standard

https://matrix.org/docs/guides/types-of-bridging/ has some text on the various kinds, also applicable to XMPP.

I can't read that page

I've tried many times before

Mentally translate "appservice" to "component".

Semi half-puppted double-backwards unplumbed bridge

I also thought I had a solid handle on bridging but am now thoroughly confused

Read the headings, guess the rest and write your own version? :D