-
MSavoritias (fae,ve)
reading through https://xmpp.org/extensions/xep-0289.html [XEP-0289: Federated MUC for Constrained Environments] as i am interested in having a multicast based group chat thing, I also noticed that it opens with: > MUC's design generally assumes a highly reliable network providing plenty of bandwidth, and it functions well in Internet settings. It is sometimes the case that server to server traffic is heavily constrained, with typical problems for constrained links being high latency, tiny amounts of available bandwidth and unreliability (including, potentially, long-term failure of S2S links). which is exactly the specs i want to have as i have mentioned before. has these been fixed after this got published in MUC? will they be fixed in MUX?
-
MSavoritias (fae,ve)
reading about it also, it seems a bit of a "hack" pardon the language
-
wgreenhouse
MSavoritias (fae,ve): fmuc is implemented only by isode's server afaik
-
wgreenhouse
and mix is polling, so inefficient in a new and different way
-
MSavoritias (fae,ve)
i meant MUX not MIX :) the updated MUC
-
MSavoritias (fae,ve)
polling you mean pull not push right?
-
MSavoritias (fae,ve)
i do want to go for pull as much as possible but yeah it comes with different problems altogether
-
MattJ
I'm not sure I understand how you can get to "MIX is polling"
-
MSavoritias (fae,ve)
> MSavoritias (fae,ve): fmuc is implemented only by isode's server afaik hmm. that was another one of the questions i had as i was reading this yeah. meaning: is FMUC even "supported" or should i go for something else
-
MSavoritias (fae,ve)
i get the feeling also that 0289 assumes there is a "main" room somewhere. and everything else is just mirroring the main room
-
MSavoritias (fae,ve)
because of this wording > The joining FMUC node MUST NOT send the traffic generated by these data back to the joined room, but only deliver them to local participants (and in the case of chained FMUC nodes, any nodes joined to it). It also MUST NOT pass the fmuc payloads through to local clients.
-
MSavoritias (fae,ve)
ah and it also sends presence everywhere. never mind then probably not
-
wgreenhouse
MattJ: a naive reading of the spec gave me the impression that MIX is polling at least at the c2s level, which is exactly where I wouldn't want that, if MAM is essentially the only means of getting mesaages
-
wgreenhouse
it seems as though this will be less reliably immediate even for a client with an open connection to its server
-
MSavoritias (fae,ve)
MAM is not the only way according to the spec. Its the messages node > The Messages node is used to distribute messages. The Messages node is a transient node and so no PubSub items are held. Messages MUST go to the associated MAM archive and history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them. Private Messages are not distributed by the Messages node.
-
MSavoritias (fae,ve)
so messages do go "live" to people
-
MSavoritias (fae,ve)
the transient just seems to say that they are not kept in history but instead the node is just a relay. history its MAM only
-
MSavoritias (fae,ve)
(unless i am reading it wrong that is)
-
MSavoritias (fae,ve)
coming back to FMUC this also makes it bad to deploy outside of organizations: > This allows an FMUC node to proxy for another JID, so should only be deployed in scenarios where either the FMUC nodes are trusted, or it is known that the users of an FMUC node are in the same security domain as the FMUC node itself. so yeah not for me
-
wgreenhouse
MSavoritias (fae,ve): it's hard for me to tell, tbh. there is no example of receiving normal message traffic that way, but lots of detail is provided for doing so via MAM
-
MSavoritias (fae,ve)
fair. I mean MIX is almost all theoretical afaik
-
wgreenhouse
I interpreted it as you might get a notification of new messages being delivered via the pubsub node, but your client woild then have to sync up with a MAM request
-
MSavoritias (fae,ve)
heh that would be an interesting architecture
-
wgreenhouse
similar to how lots of sillier protocols have a separate "push notification" stream but then your client has to do something else to get the content
-
MSavoritias (fae,ve)
now that i think about it some more adding distributed to MUC is a really bad idea to begin with
-
MSavoritias (fae,ve)
because the config and roster are not in any way shielded from interference or malice of a node
-
MSavoritias (fae,ve)
hmm. maybe "authenticated" actions with a signed omemo message would work. but then you basically recreated pubsub :P
-
wgreenhouse
fmuc assumes the same entity (namely US .mil who was the customer) runs all the fmuc servers
-
MSavoritias (fae,ve)
yep i saw
-
MSavoritias (fae,ve)
and the DMUC xeps just copy the config around. which got me to ask how MUC actually manages config. didnt want to know that really :/
-
MSavoritias (fae,ve)
is there any movement to make the MUC config/members list authenticated somehow and with access to specific people only?
-
MSavoritias (fae,ve)
i am thinking like MLS or Matrix did
-
wgreenhouse
looking forward to the possibility of rooms being "bricked" like we have in Matrix
-
MSavoritias (fae,ve)
what aspect are you referring to here exactly?
-
MSavoritias (fae,ve)
in the sense of how do authenticated changes lead to whatever you said
-
Guus
Openfire has experimental support for FMUC.
-
MattJ
wgreenhouse: the whole premise of MIX was "we already have pubsub which is able to broadcast stuff to a list of people in realtime, which is basically what a group chat is, so let's use pubsub for group chats"
-
MattJ
MAM is for catch-up, same as 1:1/MUC
-
singpolyma
Pubsub also has it's own history mechanism, but I guess maybe mix ignores that?
-
wgreenhouse
singpolyma: mix seems to specify don't use it
-
wgreenhouse
if that's what's meant by transient
-
wgreenhouse
don't use the history aspect of pubsub I mean
-
taba
where's the email address i send requests to for the source code of us millitary programs
-
wgreenhouse
I doubt there's just one. many agencies have their own open source programs
-
taba
:nerd-face-pensive:
-
flow
singpolyma, IIRC the idea was to use MAM also for pubsub (since pubsub is also message-stanza based), which is sensible IMHO, given that MAM is more powerful and flexible compare to what native pubsub provides
-
singpolyma
Is it? Native pubsub is pretty powerful
-
lovetox
mam is basically a way to give the server filter conditions
-
lovetox
so the more filter conditions you have the more "powerful"
-
lovetox
does pubsub even have filter conditions or is it just RSM?
-
lovetox
dont see a single filter condition, its just RSM + get me a single item by ID
-
MSavoritias (fae,ve)
either way it would recreating MAM in pubsub so probably not wise to do so
-
MSavoritias (fae,ve)
both for future advancements and for backwards compatibility
-
Kev
Broadcast FMUC (or broadcast based MUC, anyway) is a thing I’m interested in. I’m not sure I’d call FMUC a hack, it largely uses existing MUC protocol but to join a room to a room instead of a user to a room, so it’s fairly natural. It works pretty well for the use case it was designed for, which is not most people’s use case. Notably it doesn’t have a “main” room, and can be deployed between organisations, but there is a definite mutual trust requirement.
-
MSavoritias (fae,ve)
i checked the affiliated versioning also and it doesnt seem to be authenticated in any way. more of a way to reduce bandwidth
-
MattJ
The authentication would be the normal s2s authentication, and the mutual trust KeV mentioned✎ -
MattJ
The authentication would be the normal s2s authentication, and the mutual trust Kev mentioned ✏
-
Kev
In fact, in situations you want to FMUC, you frequently want to avoid S2S even and do something like X2X instead.
-
MSavoritias (fae,ve)
> The authentication would be the normal s2s authentication, and the mutual trust Kev mentioned that doesnt make much sense imo
-
MattJ
Why not?
-
MSavoritias (fae,ve)
yeah my problem is what do you do in "mutually suspicious" networks
-
MSavoritias (fae,ve)
because we already have spam accounts
-
MattJ
Sure, that's harder
-
Kev
And yes, it‘s partly a bandwidth saving mechanism, while also being a mechanism for allowing discussion to continue on the local side when the link is down.
-
Kev
> yeah my problem is what do you do in "mutually suspicious" networks Yeah, FMUC is not for that environment, and something good for that environment isn’t going to be good for FMUC cases.
-
MSavoritias (fae,ve)
so delegating checks to servers doesnt scale really. and it will become very easy to hijack the room
-
MSavoritias (fae,ve)
in an open registration environment that is
-
MSavoritias (fae,ve)
now i you have some kind of web of trust the situation changes
-
MSavoritias (fae,ve)
but 1. we dont 2. it would still be nice to have an additional assurance
-
MSavoritias (fae,ve)
especially since we have signing already in some form
-
MSavoritias (fae,ve)
> > yeah my problem is what do you do in "mutually suspicious" networks > Yeah, FMUC is not for that environment, and something good for that environment isn’t going to be good for FMUC cases. makes sense. thanks for the clarification
-
MSavoritias (fae,ve)
i understand that not having servers to fall back to, makes things complicated
-
Kev
There’s lots of interesting things to do here, and not a one size solution for competing requirements.
-
MSavoritias (fae,ve)
my first take would be to put all config/members/metadata of the room in a pubsub node.
-
MSavoritias (fae,ve)
and take the permissions model of pubsub and add signing of events
-
MSavoritias (fae,ve)
but then you have MIX :P
-
MSavoritias (fae,ve)
> There’s lots of interesting things to do here, and not a one size solution for competing requirements. sure. i understand that FMUC was made for a different set of requirments
-
Kev
Yuhhuh.
-
Kev
(yuhhuh, re mix)
-
MSavoritias (fae,ve)
then you also lessen the bandwith because you can send only things that changed and not the whole config
-
Kev
I still believe in the mix model, but I don’t know how to frame it and/or tweak protocol in a way that makes sense to people.
-
MSavoritias (fae,ve)
i keep trying to make MUC work for me but yeah :/
-
singpolyma
I was a big believer in MIX when it was "let's just use pubsub" but then in grew into a monster that wasn't that anymore and MUC already exists if I want something like that
-
MSavoritias (fae,ve)
i mean that is fair. I was mainly talking about my use case and requirments. I didnt mean to start "replacement" discussion
-
MSavoritias (fae,ve)
because it feels i am trying to twist MUC into becoming MIX
-
Kev
Maybe I should just rewrite mix as “do muc with the mix model” that fixea the core issues, and go from there.
-
MSavoritias (fae,ve)
that would be interesting yeah
-
MSavoritias (fae,ve)
like there is the server compatiblity with 408 but there is not a client compatibility
-
MSavoritias (fae,ve)
or actually a development migration thingy to reuse existing components as you said yeah
-
moparisthebest
> What happens if a test fails? Guus: your tool optionally outputs junit XML which is the universal format for CI parsing/output ↺
-
moparisthebest
Damn happened again but only happens when I'm not in a position to troubleshoot... My Cheogram can send+receive messages to MUCs and other 1:1, and wife's Cheogram can do the same, except she gets 1:1 messages from me but I get none from here until I log out and back in... Thoughts singpolyma ? It could be a prosody bug too I guess✎ -
moparisthebest
Damn happened again but only happens when I'm not in a position to troubleshoot... My Cheogram can send+receive messages to MUCs and other 1:1, and wife's Cheogram can do the same, except she gets 1:1 messages from me but I get none from her until I log out and back in... Thoughts singpolyma ? It could be a prosody bug too I guess ✏
-
singpolyma
...all your stanzas everywhere work except a single jid sending messages to you and a log out/in fixes? That might be the craziest thing I've heard today
-
singpolyma
When you log out and back in are all the things she tried to send you there from mam?
-
moparisthebest
Yes, it's actually happened multiple times, at least 4 or 5 over the last few months
-
moparisthebest
And yes I get them all from mam when I log back in
-
singpolyma
So server knows about them. Client doesn't think it ever saw them
-
moparisthebest
Note my connection has been extra flaky today so that could be a cause
-
singpolyma
Next time it happens enable debug logs on prosody and see if it thinks it it sending them to your c2s?
-
singpolyma
Since we don't have XML console in mobile to check such things...
-
moparisthebest
Yea I think I'll have to do that to be able to blame Cheogram or prosody
-
moparisthebest
Now that I think about it I was only doing muc so if online presence didn't get out somehow, that could explain me not getting 1:1...
-
singpolyma
Yes. If zero 1:1 works I have more possible theories
-
singpolyma
If it's just one contact it's bonkers
-
moparisthebest
I didn't try other 1:1 but I can next time
-
moparisthebest
I'm now wildly guessing it's a SM bug where presence doesn't make it out