jcbrandHas anyone here though about or come up with a way to identify messages from bots? Seems like one can just include a special tag and namespace for it. Is there anything like that in the wild already?
jonas’jcbrand, bots should publish a bot identity in disco#info and clients should use that
jcbrandso you should send a disco query for every single message in a MUC?
jcbrandnot really practical in certain use-cases
jonas’'115 caches
jonas’or if that’s not feasible because MUC, you can just query when the participant enters the MUC
jonas’and cache the information until they leave it
jcbrandYou can really see that XMPP was designed without ever thinking about web clients
jonas’attaching such metadata to each and every message is incredible overhead
ZashHats
jcbrandoh, I like that thanks Zash
jcbrandWe already have hats
Zash<hat>🤖️</hat>
jcbrandproblem solved
Zash😀
jonas’... *sigh*
jcbrandlol
jonas’web making everything terrible again.
jcbrandenjoy your ivory tower
jonas’jcbrand, to be clear, I’m not blaming *you*
jonas’I’m blaming the web.
millesimushas joined
flowjcbrand, out of curiosity: why doesn't the approach suggested by jonas’ work for web clients?
Zashjcbrand, isn't this MUC being web-unfriendly rather than XMPP itself?
jcbrandjonas’ yeah sorry, I don't want to be hostile, but the anti-web attitude in the XMPP community does grate a little sometimes. No big deal tho
adiaholichas left
jonas’jcbrand, fair. Let me state for the record that I am really glad for your work on converse.js, because despite the web being terrible, XMPP-IM needs a web client which is *not* terrible and you seem to be doing a fairly great job at that.
adiaholichas joined
Ge0rGwhat jonas’ said, 👍 for jcbrand
jcbrandaw shucks, thanks guys
ZashIt's really the anti-everything-except-the-web attitude of the web that irks me.
jcbrandflow: my knee-jerk response is that in various situations you can't cache/store everything across sessions like you can with desktop clients
Zashjonas’, now I need you to drop everything and make that gif. you may edit the systemd-om-nom-nom.gif 😉
jonas’jcbrand, but hypothetically, if you did the disco#info on the first message from a participant and cached that for a session (or until that participant leaves), that would be feasible and good enough, wouldn’t it?
marekhas left
marekhas joined
jcbrandjonas’: yes, but that is then not XEP-0115 compatible right?
jonas’I’m not sure '115 even works in MUCs
ZashIn theory you could cache caps-hash → disco response forever
jonas’if it did, you could sometimes skip disco#info lookups if your session has already seen the hash though if '115 worked
jonas’even that can do a lot (e.g. if the bot only hops into the room briefly and you don’t know the real JID)
jcbrandYou say that including a tag is wasteful, but in a MUC with an occasional bot post and lots of posts by other users, it seems wasteful to me to do a disco-info for each new poster
jcbrandit could be a tag on the presence, not the messages themselves
jcbrandBut it's ok, the hats thing will work for my current use-case and for the open Jabber network doing a disco query for each new occupant is probably also fine
jcbrandnot each new occupant but each new message author
flowjcbrand, you probably can re-use the disco#info information for other purposes too, so I am not sure if it is that wasteful
jcbrandUnless you want to identify bots in your occupants list...
millesimushas left
millesimushas joined
jcbrandseems very chatty to me. On a desktop client you can cache all this fairly aggressively, but on web you need to do potentially hundreds or thousands of disco info queries for every session
jcbrandOn web there is IndexedDB which doesn't have a size limit, so in theory you can use that and then your webapp is more like a desktop app, but having integrated that into Converse (via localForage), I've seen that writes are suuuuper slow.
jcbrandAnd you can't use IndexedDB in all cases
jcbrandI have some ideas on how to improve performance on Converse (basically batching writes), but haven't had the time to iron out the kinks
adiaholichas left
Ge0rGjcbrand: what about localStorage?
jcbrandlocalStorage has a 5MB limit, so if you have lots of MUCs it fills up pretty quickly
jcbrandNow you could regularly delete older messages, but then you lose your OMEMO history
jcbrandSo far that has made me reluctant to aggressively get rid of older messages
ZashI can't actually use Converse.js anymore, it runs into those limits in a few minutes 😕
jcbrandIf it wasn't for OMEMO then it would be much easier
ZashNot while joining all MUCs anyway
jcbrandZash: If you're up for it, you can try the master branch with IndexedDB
jcbrandperformance has improved a lot recently
jcbrandStill quite a bit slower than localStorage, but usable IMO (although not usable in some use-cases like having it integrated into an existing resource-hungry site)
jcbrandI might even make IndexedDB the default in the 8.0.0 release (especially if I can get the batched writes to work well)
millesimushas left
stphas joined
adiaholichas joined
neshtaxmpphas joined
jcbrandOne advantage that disco has over hats is that hats are per MUC, so you have to assign them for every new MUC the bot enters
ZashHm, reminds me of the issue of MUC-component wide affiliations and such.
Syndacehas left
Syndacehas joined
jcbrandyeah, would be great to have
jcbrandis any of this fixed or improved by MIX?
jcbrandNot that I expect MIX to supplant MUC any time soon
BASSGODhas left
adiaholichas left
adiaholichas joined
eric> eric: for which
> screen size is certainly still a problem for KDE apps, like with plasma mobile the wifi setup dialog, no one had tested it with WPA2 Enterprise, the OK/Cancel buttons were off-screen, I had to hook it up to a monitor to set it up
moparisthebest:
pasdesushihas joined
lovetoxhas left
adiaholichas left
adiaholichas joined
BASSGODhas joined
APachhas left
APachhas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
lovetoxhas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
BASSGODhas left
pasdesushihas left
BASSGODhas joined
ajeremiashas joined
BASSGODhas left
erichas left
adiaholichas left
adiaholichas joined
erichas joined
millesimushas joined
adiaholichas left
pasdesushihas joined
stphas left
pasdesushihas left
BASSGODhas joined
adiaholichas joined
stphas joined
Wojtekhas joined
alameyohas joined
BASSGODhas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
aidalgolhas left
pasdesushihas joined
alameyohas left
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
BASSGODhas joined
Guushas joined
lovetoxhas left
paulhas left
paulhas joined
paulhas left
paulhas joined
adiaholichas left
paulhas left
paulhas joined
paulhas left
paulhas joined
BASSGODhas left
Guushas left
adiaholichas joined
xeckshas left
xeckshas joined
Aleksejhas joined
BASSGODhas joined
purplebeetroothas joined
BASSGODhas left
karoshihas left
xeckshas left
xeckshas joined
karoshihas joined
BASSGODhas joined
Andrzejhas left
Andrzejhas joined
etahas joined
adiaholichas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
Andrzejhas left
purplebeetroothas left
adiaholichas joined
pasdesushihas left
Andrzejhas joined
adiaholichas left
xeckshas left
xeckshas joined
Marandahas left
Marandahas joined
BASSGODhas left
Wojtekhas left
adiaholichas joined
BASSGODhas joined
adiaholichas left
xeckshas left
xeckshas joined
adiaholichas joined
mathijshas left
mathijshas joined
xeckshas left
xeckshas joined
nycohas joined
ti_gj06has left
lovetoxhas joined
nycohas left
pasdesushihas joined
Kevhas left
peetahhas left
peetahhas joined
Kevhas joined
pasdesushihas left
andrey.ghas joined
Andrzejhas left
Andrzejhas joined
Wojtekhas joined
xeckshas left
xeckshas joined
Andrzejhas left
fuanahas joined
xeckshas left
xeckshas joined
pasdesushihas joined
BASSGODhas left
Guushas joined
pasdesushihas left
pasdesushihas joined
fuanahas left
emushas joined
pasdesushihas left
pasdesushihas joined
BASSGODhas joined
fuanahas joined
Guushas left
pasdesushihas left
andyhas left
Andrzejhas joined
andyhas joined
beanhas left
beanhas joined
beanhas left
beanhas joined
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
chronosx88has left
chronosx88has joined
chronosx88has left
chronosx88has joined
pasdesushihas left
ajeremiashas left
ajeremiashas joined
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
andyhas left
pasdesushihas left
rmlanghas joined
fuanahas left
moparisthebestI thought web apps could request more localStorage space nowadays?
moparisthebesteric: ah, no, but in general there are many more bugs than things that actually work in Linux phone land so I'm just waiting it out :)
BASSGODhas left
SamReminder that XMPP Office Hours for this week are today, not Friday! "Soprani.ca: bridging us all together" by Stephen Paul Weber (singpolyma) on Wednesday, 31st March 17:00 UTC
BASSGODhas joined
emushas left
Marandahas left
Wojtekhas left
BASSGODhas left
fuanahas joined
paulhas left
paulhas joined
paulhas left
paulhas joined
emushas joined
pasdesushihas joined
Steve Killehas left
Steve Killehas joined
pasdesushihas left
BASSGODhas joined
fuanahas left
eevvoorhas joined
test1has joined
mathijshas left
mathijshas joined
BASSGODhas left
Ge0rGhas left
Ge0rGhas joined
Wojtekhas joined
andyhas joined
BASSGODhas joined
ti_gj06has joined
test1has left
pasdesushihas joined
Marandahas joined
fuanahas joined
adiaholichas left
pasdesushihas left
pasdesushihas joined
adiaholichas joined
BASSGODhas left
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
arcxihas left
arcxihas joined
pasdesushihas left
pasdesushihas joined
arcxihas left
arcxihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
BASSGODhas joined
ti_gj06has left
pasdesushihas left
pasdesushihas joined
ti_gj06has joined
adiaholichas left
fuanahas left
fuanahas joined
pasdesushihas left
Tobiashas left
Tobiashas joined
Andrzejhas left
Andrzejhas joined
adiaholichas joined
emushas left
chronosx88has left
chronosx88has joined
SamOffice Hours for this week (about jmp.chat) is starting now! https://socialcoop.meet.coop/sam-pku-dud-niv
fuanahas left
adiaholichas left
emushas joined
adiaholichas joined
test1has joined
test1has left
adiaholichas left
mathijshas left
mathijshas joined
lskdjfhas left
adiaholichas joined
paulhas left
BASSGODhas left
paulhas joined
test1has joined
lskdjfhas joined
pasdesushihas joined
rmlanghas left
test1has left
BASSGODhas joined
test1has joined
test1has left
pasdesushihas left
fuanahas joined
lskdjfhas left
lskdjfhas joined
BASSGODhas left
lskdjfhas left
lskdjfhas joined
rmlanghas joined
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
BASSGODhas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
BASSGODhas left
Wojtekhas left
rmlanghas left
pasdesushihas left
pasdesushihas joined
rmlanghas joined
flowGe0rG, why are groupchat messages in an user archive a bad idea?
Wojtekhas joined
Ge0rGflow: because the client needs to support that, be aware that those come from a MUC, and treat them differently. I think that the MUC MAM approach has worked better.
Ge0rGMost clients today will probably do weird things when receiving groupchat messages from MAM
pasdesushihas left
fuanahas left
pasdesushihas joined
lskdjfhas left
lskdjfhas joined
lovetoxhas left
flowGe0rG, thanks for the reply. But I've to admit that this appears to be more like a client issue
pasdesushihas left
pasdesushihas joined
lskdjfhas left
lskdjfhas joined
ZashThere's also the problem with how a MUC will send one message for each joined resource, which complicates server processing.
ZashWay simpler for the MUC to do it, as it already knows when processing that it's a single message, before it broadcasts it.
BASSGODhas joined
Ge0rGflow: a MUC will only send messages to you while at least one client is connected. If you only have one client, you will only receive from MAM what you already had before. If you have two clients, you will receive a random subset of the room history with no way to know where there are holes
ZashThere are scenarios where it's desirable that the user only sees history from when they're joined, but it does get weird and should probably be dealt with on the basis of affiliation.
pasdesushihas left
Ge0rGIt's getting even more weird with MIX MAM, and I've been telling that for years.
KevBTW, saying “no-one does this” isn’t correct :)
pasdesushihas joined
ZashThis is the point where I mention that experiment I did in rewriting outgoing MUC joins so that they come from the bare JID?
KevBut you’re right that it doesn’t work terribly well.
Ge0rGKev: I'm eager to read your implementation and interop story on the ML
pasdesushihas left
ZashGe0rG, what about MIX MAM ?
Ge0rGZash: you could convert that from a 20% implementation to an 80% implementation, and I'd actually test it
Ge0rGZash: s2s isn't flawless, it will cause holes in MAM
KevIf we have a MAM meta-search that searches each archive, we could probably get away without having mix history in personal archives.
fuanahas left
ZashGe0rG, but how will I be motivated to work on it without at least someone testing it?
pasdesushihas left
Ge0rGZash: well, how am I supposed to test it if it breaks everything?
ZashSomeone needs to go push the stalemate resolution button!
pasdesushihas joined
BASSGODhas left
ZashAnd there's like 3 different bookmarks methods atm, that seems fun to deal with
fuanahas joined
BASSGODhas joined
ZashGe0rG, track what outgoing presence?
adiaholichas left
Ge0rGZash: room joins from clients?
ZashThat part should work afaik
adiaholichas joined
pasdesushihas left
Ge0rGWhat about error handling?
ZashThat goes under "leave"
Zashwhich is under TODO
pasdesushihas joined
ZashI think it even dedups additional joins, tho I'm not sure that's optimal.
fuanahas left
test1has left
Ge0rGZash: it's a server module in a state I can't possibly deploy on a production server, and I'm only using one single room from my other server
rmlanghas left
adiaholichas left
ZashShould set up that bleeding edge Prosody instance for client devs ... one day.
Ge0rGYeah, crash me!
pasdesushihas left
Wojtekhas left
KevWhat rules would be needed? Just rewrite anything going to/from a MUC so that the user part is bare?
KevDetermining it’s a MUC by the first thing that’s sent being a presence with muc in it?
Ge0rGKev: you need to implement a bouncer that will multiplex the room between all your clients
KevOh yeah, that.
KevSo, basically imprementing MIX-PAM, in other words.
ZashPretty much
Ge0rGKev: kinda sorta
Ge0rGWell, it's probably not so much to implement, and doesn't need to persist anything. But it might have to do sophisticated things with room history generation on join
ZashKeep track of joined rooms, joined resources to deal with rewriting in- and outgoing stanzas. Then subject and participants which lets you add new local resources and send them a synthesized join presence flood.
adiaholichas joined
KevSo, it’s much worse that just implementing MIX-PAM.
ZashNo, it's better because it works with MUC, which is what Everyone™ is using today.
ZashWith zero changes required of clients
KevI mean it’s much worse to implement.
Ge0rGAnd with a manageable overhead on the server
ZashSure, it's MUC
winfriedhas left
KevYou know what it is like implementing, actually?
fuanahas joined
KevIt’s basically implementing FMUC.
KevWhich is a MUC implementation that can join another MUC.
winfriedhas joined
ZashFMUC-on-your-JID
ZashBecause we need more things-on-your-JID! 😀
KevIt’s the bastard child of MIX-PAM and FMUC.
Ge0rGAnd implementing it will give a significant immediate benefits
Ge0rGMobile clients don't need to self ping any more
ZashNow the server will need to self-ping! 😀
ti_gj06has joined
Ge0rGYou'd get reasonable push integration
Ge0rGLess presence flooding of rooms
Ge0rGZash: the server knows about its s2s, so it only need to self ping after s2s went down
ZashCould probably do the presence versioning thing, closer to the user.
adiaholichas left
Ge0rGZash: needs new protocol
ZashHm?
Ge0rGKev: that solution is 100% transparent to existing implementations both on the client and on the MUC
ZashIn theory you could do the same thing but have it speak MIX
KevIn theory you can do anything with enough monkeys and typewriters, yes :)
ZashNo idea if MUC-MIX translation is easier on the users' server or the MIX host.
KevMIX. Much :)
BASSGODhas left
Andrzejhas joined
ZashGe0rG, FWIW I think it's okay to leave the door open for storing groupchat messages in the users local archive, but Something Needs To Be Done first.
pasdesushihas joined
Ge0rGZash: yes, a new XEP needs to be written.
Ge0rGNo place in 313 for this
KevIs it worth having to bump the namespace for the sake of changing the SHOULD to the MUST?
ZashUgh
Ge0rGI remember having to explain to another developer not to do it like written in the XEP
Ge0rGKev: which one?
pasdesushihas left
BASSGODhas joined
KevMAM.
ZashLet's not bump any namespaces
KevI think changing a SHOULD to a MUST would require that.
adiaholichas joined
BASSGODhas left
ZashSHOULD NOT then?
Zashor perhaps a PLZ DONT
pasdesushihas joined
adiaholichas left
chronosx88has left
adiaholichas joined
Ge0rGKev: there are 14 SHOULD and a dozen should.
pasdesushihas left
Ge0rGSo which one are you talking about?
fuanahas left
fuanahas joined
ZashThe one closest to the word 'groupchat' I would have presumed?
pasdesushihas joined
Ge0rGSo...
> A server ~SHOULD~ MUST also include messages of type 'groupchat' that have a <body>
I really hope that's not the intention
adiaholichas left
KevYou proposed onlist changing into MUST NOT store gcs.
KevI think.
BASSGODhas joined
Ge0rGKev: last time I checked, MUST NOT was the opposite of MUST, so please excuse my confusion. But yes, I suggested that.
Ge0rGAs an escalation of "SHOULD NOT", but I like strong words.
chronosx88has joined
Ge0rGI also looked up that the first time I wrote "MAM subscription" on list was in 2015, and probably even earlier in here.
fuanahas left
Syndacehas left
Syndacehas joined
ZashThis is a wordification of what future (currently unreleased) Prosody will do, if nothing changes before the next major release:
- **Do not** store messages of type headline since these are supposed to be for transient notifications, most often PEP events.
- **Do store** messages of type error, since if you sent a message it is of interest to know that delivery failed.
- **Do not** store messages of type groupchat, as MUCs will send one message per joined resource and most often provides their own MAM.
- Follow \[XEP-0334: Message Processing Hints\] advising for or against storage.
- **Do store** messages with a `<body>` and/or `<subject>` element, as these carry messages for users.
- **Do store** encrypted messages for the same reason as with `<body>`, as indicated by \[XEP-0380: Explicit Message Encryption\].
- **Do store** messages with \[XEP-0184: Message Delivery Receipts\] requests, and the receipts themselves, as if something is important
enough to need such a receipt it is probably important enough to archive.
- **Do store** messages with \[XEP-0333: Chat Markers\], for the same reasons as with receipts.
- **Do store** MUC invites, both mediated and direct.
- **Do store** messages with an \[XEP-0353: Jingle Message Initiation\] payload, as users will want to know if they had missed calls.
- Anything not covered by this point is either something new that may or may not warrant adding to the archive or something that should
not be archived.
KevAnd I don’t think you’re even the first person to suggest mamsub ;)
pasdesushihas left
adiaholichas joined
BASSGODhas left
alameyohas joined
marekhas left
marekhas joined
flowGe0rG, I like you response on the ML, but you may want to consider adding reasons against groupchat messages in a user archive. I think your mail contains none, and the reasons are good. I feel we often discuss on the mailing list stating "everyone knows that X is a bad idea", without actually providing any reasons/arguments why it is so. And that probably deters people from participating.
adiaholichas left
Ge0rGflow: thanks! I'm not going to be at a proper computer for the next days, so feel free to summarize, link or copy paste what we discussed here today
xsfhas left
Andrzejhas left
fuanahas joined
BASSGODhas joined
pasdesushihas joined
alameyohas left
xsfhas joined
Yagizahas left
adiaholichas joined
lskdjfhas left
BASSGODhas left
pasdesushihas left
adiaholichas left
fuanahas left
lskdjfhas joined
Andrzejhas joined
lskdjfhas left
lskdjfhas joined
lskdjfhas left
lskdjfhas joined
fuanahas joined
lskdjfhas left
lskdjfhas joined
Andrzejhas left
sebastianhas left
Andrzejhas joined
sebastianhas joined
BASSGODhas joined
adiaholichas joined
Andrzejhas left
lskdjfhas left
DebXWoodyhas left
adiaholichas left
adiaholichas joined
KevIf you were to do dedupe on the server, or whatever, you could also achieve reasonable groupchats in the archive behaviour.
KevAnd probably for less work than trying to implement the MUC-PAM discussed earlier.
ZashThat's a big and messy if tho
KevUnlike finding a way to do dudupe and everything else involved in MUC-PAM? :)
KevI’m just giving another reason that I think MUST NOT would be excessive.
ZashJust Unfork Stuff™
ZashKev, I agree tho, if you do go and solve that and other issues, storing groupchats in the users archive is probably okay.
andrey.ghas left
adiaholichas left
BASSGODhas left
mathijshas left
mathijshas joined
chronosx88has left
chronosx88has joined
Ge0rGKev: also please solve reliable s2s while you are at it. And World Peace. Whatever is easier.
adiaholichas joined
chronosx88has left
chronosx88has joined
lskdjfhas joined
ZashYou know what, let's flip that default
mdoschhas left
mdoschhas joined
Ge0rGKev: you need additional protocol to get MUC messages into the user account, even when no client is connected, which is surprisingly close to MUC-PAM
Ge0rGWithout that, you get invisible holes in MUC history, which is the opposite of what xmpp needs
fuanahas left
DebXWoodyhas joined
BASSGODhas joined
eevvoorhas left
adiaholichas left
fuanahas joined
papatutuwawahas joined
adiaholichas joined
fuanahas left
deuillhas left
chronosx88has left
chronosx88has joined
pasdesushihas joined
BASSGODhas left
adiaholichas left
ti_gj06has left
BASSGODhas joined
pasdesushihas left
adiaholichas joined
BASSGODhas left
Tobiashas left
adiaholichas left
Tobiashas joined
flownot sure if we MUST keywordify here, it appears a simple "we found that user archives with type=groupchat messages cause trouble if not taken special care of, and clients may want to consider ignoring type=groupchat messages in a user archive"
flowcould be sufficient
fuanahas joined
beanhas left
BASSGODhas joined
nad200has joined
adiaholichas joined
jcbrandhas left
KevMakes sense to me.
adiaholichas left
Tobiashas left
adiaholichas joined
fuanahas left
adiaholichas left
Ge0rGI still think that servers shouldn't send all the MUC garbage to a client
erichas left
Kevhas left
Kevhas joined
goffihas left
deuillhas joined
Kevhas left
Kevhas joined
adiaholichas joined
emushas left
Lancehas left
adiaholichas left
BASSGODhas left
nad200has left
BASSGODhas joined
nad200has joined
Kevhas left
Kevhas joined
nad200has left
Lancehas joined
adiaholichas joined
nad200has joined
Kevhas left
Kevhas joined
adiaholichas left
Kevhas left
Kevhas joined
Andrzejhas joined
debaclehas left
papatutuwawahas left
LNJhas left
edhelashas left
edhelashas joined
moparisthebestLooks like XMPP infringes on this patent in the USA, </stream:stream> illegal:
> The claimed invention is a system where at least one robot “generates a goodbye command that terminates a communication session” with another robot and “relinquishes control.”
https://www.eff.org/deeplinks/2021/03/stupid-patent-month-telehealth-robots-say-goodbye