XSF Discussion - 2023-03-06

https://xmpp.org/extensions/xep-0401.html seems to be on last call that ended 2021 according to the red text. I suppose some new status belongs there ✏

There is no way to map an occupant id to the members, admins list is there?

On its own, no

You'd have to observe <presence> or whatever

I wondered recently about just inserting it into the affiliation responses

Outch, the O(n^not fun)

I think we cache it thou... oh right, not for offline folk

affiliations ≠ occupants

> You'd have to observe <presence> or whatever Yes I was thinking about offline contacts

Also in XEP-0463.

Hm, but they're based on bare jid?

Brain too full of OAuth to swap in another XEP

Yes they should be based on bare jid

Then it should be doable (and relatively cheap) to include anywhere we have affiliation

if we want occupantId to be the one stable thing that identifies people in muc it should probably be everywhere

so I can map the different sources of "people who are in a muc" and merge them properly

and look up the "real sender"

(jid, nick, occupant-id) tripplets everywhere

(jid, nick, occupant-id, origin-id, stanza-id)

I’m not the one who killed mix

Ge0rG, fastening-context, version number?

Daniel, MIX relates to this how?

MIX is dead?

Weren't we all going to implement MIX over the weekend?

mix has stable participant ids by default

no resource vs occupant id

I thought it had real JIDs for everyone by default, and some proxy service (not included) ✏

real JIDs are the most stable IDs

yes real jids are included too. but messages originate from room@service/participant-id

and this maps to the item id of the participant node if you want to look up more information

Invent some MUC join options, one of which would be to send messages from room@muc.service/occupant-id ✏

Rewrite the nick into XEP-0172 elements or somesuch

> Invent some MUC join options, one of which would be to send messages from room@muc.service/occupant-id I could live with that

And then more and more MUC options until finally we have a "just use MIX" MUC option :)

When I previously brought up something similar people argued that some clients might not support muc initiated nick rewrites

"Don't send presence" being another such option

Yeah, if we just do it without opt-in

Feature flags sure ... moves some pain around

I think it would have to be a channel wide setting. Otherwise you can't rely on that as the one who is parsing the messages

Isn't that just "use MIX instead" then?

Wait nick rewrites? Isn't that a different thing

Muc can tell you 'your resource (nick) is x now' instead of the one you tried to join with

There could be a muc setting where the muc tells everyone your nick is occupant id now

I mean <presence><{muc}x><{fancy-new-options}swap-nicknames-and-occupant-ids/><//> (check disco first) and then you get a different kind of broadcasts

Ah

Mhh maybe

That sounds complicated

Because it would have to change the resources in the MAM response too

Sure, yeah.

If people prefer something like that to mix I'm fine with it

I imagine it would be the same class of complexity as implementing MIX protocol on top of existing MUC code

Hello all. (Sorry for cross posting…) I’m experimenting a bit with bridging OpenAI chat and the XMPP network, to see what this can be used for. If anyone is interested to try, you can chat with xmpp:chatgpt@lab.tagroot.io. Image generation can be tested by chatting with xmpp:dalle256@lab.tagroot.io, xmpp:dalle512@lab.tagroot.io or xmpp:dalle1024@lab.tagroot.io. For more info, or QR-codes to the above JIDs, https://lab.tagroot.io/Community/Post/OpenAI_integration_with_the_Neuron ✏

While the gateways above have minimal instruction, it is possible to fine-tune a model with up to 1 GB data using a dedicated instance it seems. It would be possible to make a bot, for instance, that can learn about all XEPs and then help people to find relevant XMPP-related information.

a fun endevaor. did you also try to put it in a muc?

I was thinking about it, but didn’t get a clear idea on how it would operate. It would be annoying if it inserted itself into everything. Perhaps it could stay silent, and only monitor communication (to learn) and inject a comment/response if asked directly (or via a private channel)

react only if mentioned first of course

I have a markov chains XMPP bot, millions of dev hours in AI development, no use case that isn't also filled by markov chains from 1906, they have played us for absolute fools

Yet another fad that can get you money from VCs I guess

we could let the two bots talk to each other 😛️

https://code.moparisthebest.com/moparisthebest/ash is the source, you can play with it in a few MUCs, one is xmpp:conversations-offtopic-reloaded@conference.trashserver.net?join

open source apps are the best

I've written some open source apps that can disprove that :)

Personal opinion: open source is required for an app to be good, but is not alone sufficient to be good, in fact nearly all software sucks :)