jdev - 2022-09-11

I'm confusing which JIDs should go where.. what kind of terminology do you use for your MUC-component impls? - roomjid, barejid of the room - occupant? Many resources (fulljid) from the same account to one participant fulljid - Session? A real(full)jid. - Anything I'm missing?

- Participant -- which I named in the occupant line --, fulljid for the occupant in the room

Don't look to Prosody for inspiration here... most of the variables called 'nick' contain an occupant's room JID

That "most" is the best part

^^'

Gradually cleaning that up

Occupant JID is generally clear, I think

And real JID is always clear

Occupant JID being.. what I called participant jid?

In my list above, an occupant isn't actually visible from the outside

Maybe I should just call that occupant jid yeah

Well it's visible as a participant

But I guess I just took that word from roles and it's not actually needed ✏

Yeah realjid is always clear to me too

Even though.. it can be full or bare

That's why I also like session

Apart from the multi-session nick stuff, MUC is pretty much based on full JIDs only

I start a new MUC implementation, I'm going to include MSN :p

Though given trends, it may be something I'd change in a new implementation

But yeah I realized it was mostly fulljids. I was a bit surprised coming mostly from the client side

When sending presences at join, I send occupant presences right, not sessions. Unless in non-anon rooms, or.. is it that I just include multiple realjids in the presence?

when you master all this, will you help me with slidge's MUC support pep, please? 🙂 ✏

heh

Or I just include one of the session jid, and which one is implementation defined?

Because MSN wasn't planned from the start so it's just not there

pep.: Prosody sends multiple real JIDs in presence, though it's not in the spec (or wasn't, can't remember if we updated it)

“If allowed by the service, a user can associate more than one full JID with the same occupant JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.” ✏

What does this look like in XML? multiple <item/>?

Yes

ta

https://xmpp.org/extensions/xep-0045.html#bizrules-presence > A room MUST silently ignore unavailable presence received from a user who has a role of "none". It seems like prosody is sending cancel/service-unavailable instead? That's when a realjid has no existing session and sends an unavailable presence (with no payload). Prosody also sends the same when an there's an existing session but the unavailable presence comes from another resource. But I guess here that may be ok?

I'm not sure why the MUST NOT, I don't see what harm it causes

But it's probably just oversight on our part... we return that error for any stanza not "handled", by default

So MUC probably does ignore it, and then Prosody sees no code did anything useful and lets the sender know with an error

Yeah I'm also not sure, both make sense I guess

role = none? means im kicked?

can a joined user have role = none

does this not simply mean, dont broadcast presences for not joined users?

or it goes into this direction to not confuse clients

with presence broadcasts

Uh, well, we might all be talking about different things

I was talking about the response to the sender

It obviously shouldn't be broadcast

Now I'm not sure what pep. was talking about

The response to the sender yeah

My guess is that the XEP is thinking about broadcast at this point

Which makes the MUST seem more sensible

More than sensible 🙂

That's what I meant, the xep probably wants to say "don't follow the normal muc rules for this presence" ✏

But silently ignore is probably to much

Random picture of Ralph half way through this article, plus a secretly planted XMPP mention in the middle (even though the article isn't about that): https://www.forbes.com/sites/michaeldelcastillo/2022/09/11/jack-dorseys-former-boss-is-building-a-decentralized-twitter/?sh=1b053b5457c3

403. Another website that doesn't like Tor.

Or https://www.forbes.com/sites/michaeldelcastillo/2022/09/11/jack-dorseys-former-boss-is-building-a-decentralized-twitter/ with the creepy tracking link removed

I guess Mastodon wasn't decentralized enough for Jack.

TIL about Twetch. "Decentralized social network -- where everything lives on the blockchain". Are they being serious?

blockchain is some magical place

atleast... that's what they say