SeveBy the way, regarding the email I sent to JUser, is there a better mailing list for that, please?
jonaswI still haven’t subscribed to juser :/
SeveThat's why I would like to send it somewhere else too, seems not many people are subscribed there
jonaswSeve, I think operators would be more fitting, maybe
rionhas left
jonaswpossibly with a cross-post to members@
jonaswI’m also not sure if a separate MUC for this is a good idea
ZashPosted something to some KDE list?
rionhas left
rionhas left
jonaswfrankly, I’m not sure XMPP can fulfil the requirements at this instant in time
jonasw> Stickers are available
jonaswwe doomed
ZashFind out which are requirements and which are wishlist
jonaswZash, they don’t even know that yet
rionhas left
jonasw> Requirements are not prioritized (incl. must-have vs. nice-to-have), that comes at a later step.
rionhas left
Martinhas left
jubalhhas joined
rionhas left
danielhas left
Zashjonasw: All are wishlist. There's online one requirement, that everyone you care about is already using it. :)
andyhas joined
tim@boese-ban.dehas left
rionhas left
Sevejonasw, the point of the MUC is to discuss this topic with people interested in helping out. Almost everybody here would find this discussion annoying here.
jonaswSeve, I’m running out of screen space for more MUCs.
rionhas left
rionhas joined
tim@boese-ban.dehas joined
rionhas left
andyhas left
marcGe0rG, jonasw can you review https://git.zapb.de/xeps.git/commit/?h=fix_xep_0401&id=52725e993987f205dc253cc5a4e6937fe3955d81 and merge please?
uchas joined
moparisthebesthas joined
jonaswmarc, EBUSY right now
jonaswmarc, if you refuse to make a github PR (which would really be the most useful thing for me), please send an email with the first line of the commit message as subject to editor@xmpp.org
marcjonasw, I can do a GitHub PR if you like
jonaswmarc, that would be much appreciated, thanks
jubalhhas left
marcjonasw, you're welcome
jonaswgotta run now, see you
marcbye
Martinhas joined
moparisthebesthas joined
rionhas joined
marcdone
Alexhas left
jjrhhas left
Zashhas left
rionhas left
rionhas joined
rionhas left
jubalhhas joined
valohas left
valohas joined
jubalhhas left
rionhas joined
andyhas joined
suzyohas joined
Zashhas joined
hanneshas joined
danielhas left
hanneshas joined
remkohas left
remkohas joined
jubalhhas joined
andyhas left
jubalhhas left
andyhas joined
jonaswzinid, regarding the server capabilities invalidation, how about a message?
jonaswserver changes caps -> server sends <message/> to local clients. for server-to-server links, it could simply close the link so that the peer re-opens it, thus getting new stream features
Alexhas joined
remkohas joined
zinidjonasw, closing and opening thousands of s2s will create avalanche effect
jonaswright
zinidwe see this on jabber.ru for examlpe
zinidso I just think about nonza
zinidstream-level element
jonaswzinid, thanks for your input, I’ll post a few suggestions to the mailing list and I hope you’ll comment on them :)
zinidsure 😉
suzyohas joined
intosihas left
andyhas left
moparisthebesthas joined
Dave Cridlandhas left
moparisthebesthas joined
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBonesIs there a good resource on the problems with message ids?
jonaswzinid, replied, happy to hear from you d)
jonaswzinid, replied, happy to hear from you :)
jonaswSaltyBones, I’m not sure
SaltyBonesI'm looking at XEP-0359 but the problems mentioned at the summit are not in there.
jonaswmaybe the summit notes as first starting point
hanneshas joined
jubalhhas joined
andyhas joined
jubalhhas left
Syndacehas left
Syndacehas joined
suzyohas joined
SaltyBones1.2 Stable IDs
Discussion on entropy ensues.
dwd: <stanza-ids> don't work for unique addressing because we don't trust clients to do them properly.
Kev: lots of possible attacks with spoofable stanza IDs.
SaltyBonesNot verbose enough.
jonaswSaltyBones, I think the gist of that is: we need to generate stanza IDs on the server because weak/constructed stanza IDs are a problem. but the client needs to know the stanza ID for archive operations and possibly other things
zinidjonasw, well, dunno, for me message looks too complex
Martinhas left
zinidcan't we just send <c/> as a nonza?
jonaswzinid, I think RFC 6120 would slap you in the face for that ;-)
jonaswreally, it needs negotiation
jonaswit’s a shame that we have no way for a client to send stream features :(
zinidyeah, because some implementation may close a stream if they receive unrecognized nonzas
jonaswyupp
jonaswI know at least one.
zinidhowever, I tried to implement such behaviour (closing a stream) and got lots of problems and left the idea
jonaswnever had issues so far; did you encounter things which sent unsolicited nonzas?
zinidalas, I've already forgotten what that was exactly 😕
jonaswzinid, the best we could do is probably say "okay, if the client sent a presence update with caps, we can send a nonza with a caps update"
jonaswand similarly for servers ("offered caps in stream feature -> send nonza")
jonaswbut I don’t know enough about s2s to be sure that this works
jonaswthis would definitely need a namespace bump though
zinidwell, we're talking about new caps xep?
zinidwe can do it there
jonaswyeah, it requires a namespace bump there too ;-)
zinidcan't we just negotiate this feature?
Dave Cridlandhas left
zinidnot sure how
jonaswnegotiation will add a round-trip
jonaswwhich people will react very adversely to
zinidah
jonaswbut please comment on-list, hoping to get more input on that
zinidI don't know what to say
Dave Cridlandhas left
jonaswwhat you said here, essentially?
la|r|mahas joined
lskdjfhas joined
andyhas left
Dave Cridlandhas left
remkohas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBonesThere are stanza-id and origin-id in XEP-0359. Somebody at the summit also mentioned "message-id" is that defined somewhere?
MattJThey were probably referring to the id attribute, I guess?
Dave Cridlandhas left
SaltyBonesMattJ, this https://tools.ietf.org/html/rfc6120#section-8.1.3 ?
MattJYes
SaltyBonesthx
MattJThe reason XEP-0359 exists is because the id attribute is controlled (and can only be trusted by) the original sender of the stanza
MattJIt's really just designed for tracking errors, though a couple of XEPs have re-used it for other purposes
Dave Cridlandhas left
suzyohas joined
Martinhas joined
Dave Cridlandhas left
suzyohas joined
remkohas joined
Dave Cridlandhas left
SaltyBonesThe id-attribute you mean?
jonaswyes
SaltyBonesSo, I guess, stanza-id is used by MAM and origin-id is used to detect MUC reflections (that's what 0359 says anyway). And id-attribute is used for errors but the error will have the same id-attribute iiuc, right?
jonaswyes, pretty much
jonaswexcept that origin-id won’t work with all MUCs
SaltyBonesWhy?
andyhas joined
jonaswbecause not all MUCs may be able to reflect that ID for whatever implementation specific reason
jonasw(just like not all mucs can reflect the message @id)
Zashhas left
MattJThere is only one implementation I'm aware of that doesn't (didn't?) reflect @id, and I'm not even sure of the current status of that
SaltyBonesOkay, so why does the standard not just mandate that it be reflected?
MattJSimple oversight I suspect
Dave CridlandSaltyBones, Non-MUC things pretending to be MUC, in part.
Dave CridlandSaltyBones, Also by the time people had noticed this was a problem, enough implementations didn't.
SaltyBonesSo, could this be fixed by changing the standard and requiring that origin-ids be reflected?
Dave Cridlandhas left
SaltyBonesDave Cridland, what do you mean by "non-muc things pretending to be muc"?
jonaswSaltyBones, changing the standard doesn’t fix the implementations magically
MattJDave Cridland, enough = 1? Also in the case of bridging to non-MUC, isn't it as simple as 1) if the non-MUC supports acks, wait for the ack and reflect the id or 2) reflect the id immediately?
jonaswSaltyBones, IRC transports are "non-muc things pretending to be MUC" for example
SaltyBonesjonasw, not magically but ...
Dave CridlandMattJ, More than one, I think. One classic MUC implementation, but quite a few transports.
uchas joined
Dave CridlandFWIW, I've gone back and forth over whether MUC ought to reflect ids. It's a special case of maintaining the id on bradcast, which is itself both useful in some cases and bad in others.
SaltyBonesWhy is this reflection necessary?
Dave CridlandSaltyBones, Reflection isn't - we could add in a subelement which indicated the original id.
Dave CridlandSaltyBones, Broadcast ids are harder to work around - there's a few protocols which use id as reference.
Dave CridlandThis all said I *really* dislike having a zillion ids as subelements of stanzas when we already have an id attribute.
Kevhas left
SaltyBonesWell, what is the subelement necessary for? Is this just as an ACK to the client?
SaltyBonesWhat do you mean by broadcast-id?
Dave Cridlandhas left
MattJSaltyBones, if you're asking why MUC reflects messages to the sender in the first place (some systems, e.g. IRC don't) - it has a few benefits
MattJSuch as ensuring everyone in the room sees the same messages in the same order
jonaswit also is natural as soon as multiple clients are in the play, somewhat like message carbons
Dave CridlandSaltyBones, So the id attribute in the message stanza for a groupchat message sent to the MUC can be reused in the reflected message, and/or the broadcast messages to other participants in the group.
MattJIn IRC if two people send a message at the "same time", the messages will be shown in a different order on both their clients
MattJand yes, multiple clients from one user in the room
jonaswit allows MUCs to do fancy things to messages and still have everyone see the same thing
Dave Cridland(As a side-note, Matrix achieves a similar goal by a complex hash chain)
andyhas left
MattJSaltyBones, and also servers modifying messages (e.g. in the Prosody MUC we automatically convert long multi-line messages to a pastebin link). The reflection allows the sending client to see what everyone else sees.
remkohas joined
andyhas joined
jonasw(in contrast to IRC, where you don’t see that your message was truncated)
SaltyBonesOkay, pretty convincing...
MattJDave Cridland, and as many people at FOSDEM noted, much RAM
Dave CridlandMattJ, Yes but BLOCKCHAIN.
jonasw#bingo #triggered
SaltyBones🔲⛓️
Dave CridlandI hope there's a ZWJ there.
moparisthebesthas joined
SaltyBones*Yes, there is.*
Dave Cridlandhas left
SaltyBonesOkay, so we want reflected messages. Sounds fair. Let's suppose for a second that we can just make them mandatory in the standard and people would add them.
jonaswthey *are* mandatory
jonaswthe issue is with message IDs
jonaswclients need to be able to recognize the reflection
SaltyBonesYou mean id-attribute?
jonaswor any ID really
jonaswid attribute would be easiest
Dave CridlandWe could indicate in disco if ids were stable.
andyhas left
jonaswwasn’t that proposal rejected-ish?
SaltyBonesOkay, 1. is the origin-id used for anything else and 2. is the whole point of origin-id not to detect reflection?
moparisthebesthas joined
jonaswspeaking of MUC, I think the vote on https://github.com/xsf/xeps/pull/559 expired, didn’t it?
Ge0rGI've attemtped to fix MUC reflected IDs some years back, not even in the normative language but merely by fixing the examples
Ge0rGAnd got significant flack for it.
Ge0rGI also attempted to make origin-id == message-id, but it was refused by the XEP author.
SaltyBonesgroans.
Ge0rGNow I'll just sit and wait, and ocassionaly proclaim: *I told you so!*
SaltyBonesSo, is the point of origin-id to be used for reflection or is there something else?
FlowSaltyBones, that is one use case
lumihas joined
SaltyBonesGe0rG, great, if you could also occasionally chime in with reasons for things and explanations that would be awesome.
SaltyBonesFlow, like?
Ge0rGSaltyBones: it's mainly for reflection, except that MUCs are not guaranteed to keep non-body elements in the reflection
Flowother use cases include finding your own messages in a archive
Ge0rGSaltyBones: yes, but you don't know the stanza-id for the messages you sent
SaltyBonesGe0rG, would you say this is a requirement by nature or just a problem with implementations?
danieli agree that the xep should specify that the sender should set origin-id=message-id
Ge0rGSaltyBones: what?
Ge0rGdaniel: MUST set.
SaltyBonesGe0rG, the fact that MUCs don't reflect non-body attributes.
danielyes
Ge0rGbecause anything different is just a path into insanity
daniel(i didn't mean SHOULD)
SaltyBonesGe0rG, also, why do I need the stanza-id for a message I sent?
Ge0rGSaltyBones: have a look at biboumi, a modern IRC transport. It doesn't reflect your message ID, it doesn't reflect any non-body elements and it mangles multi-line messages
Ge0rGWelcome to message tracking hell.
danieli think thinks will already break if some client doesn't do that and then expects a delivery reciept or something
Ge0rGSaltyBones: because when you ask for a MAM sync, you'll get yout sent messages copied to you as well
danielwhen sending messages to Conversations i mean
Ge0rGYes, message correction, delivery receipts and anything else that references IDs is a mess already.
SaltyBonesGe0rG, and why is that a problem? They should have their origin-id and be recognizable, right?
Ge0rGSaltyBones: you can't rely on origin-id being there, and you can't rely on it matching the message-id.
SaltyBonesdaniel, what breaks when a client does what?
Ge0rGSaltyBones: but yes, you can match MAM archives based on origin-id
danielif an origin id is set Conversations will use that as a reference in the receipt
danielso if your client doesn't do id=origin-id and expects the receipt for the id it won't work
danielsame with everything else that references ids
SaltyBonesSo, there seems to be consensus at least in this MUC right now that attribute-id should be the same as origin-id?
danieli'd argue there is no good reason not do make this a MUST
danieli mean most client would naturally do this anyway
SaltyBonesGe0rG, who was the xep-author who was against this and do you remember why?
jonaswSaltyBones, Flow
danielbecause why would you generate a second id if you can reuse the existing one
danielnote that muc rewrites a irrelevant to the scenerio described above
Dave Cridlandjonasw, #559 expired, yes.
zinidThis is to track its own messages?
danielzinid, yes
danielor references to that
Dave Cridlandjonasw, But with no veto and the rest are +1, so apply it.
Dave Cridlandhas left
SaltyBonesjonasw, what is this ID-rewriting MUC shit? :)
danielsome mucs are known to change the 'attribute' id
Ge0rGSaltyBones: have a look at examples 44 and 45 in https://xmpp.org/extensions/xep-0045.html#message
danielso tracking your own message are parsing references don't work
ziniddaniel: why, you can rely on origin-id in this case
Ge0rGIf we have a MUC that rewrites message IDs, can we mandate that it also MUST rewrite references in all XEP payloads that reference message IDs, please?
danielzinid, in the case of muc? because most mucs won't remove child elements from the stanza
zinidI'm lost
ziniddaniel: but that's exactly what's needed
danielnow i'm lost :-)
zinidSo you can fetch origin-id and check if this is your id
Kevhas joined
jjrhhas left
zinidWhy do you need to rely on message-id if you inject origin-id
danieli just said the sender should set id=origin-id
SaltyBoneszinid, I think there was a sub-discussion about forcing message-id = origin-id
danieland/or deal with delivery receipts that reference the origin-id instead of the id
danielwhich is made easier if you id=origin-id
zinidOk, I don't get it 🤔
danieldoesn't matter. that client to client stuff anyway :-)
la|r|mahas left
la|r|mahas joined
remkohas joined
zinidFrom what I understand we just need to ditch IRC transports
zinid😃
jjrhhas left
zinidThat's really their problem
danieloh yeah. or make irc transports track the messages themselves and re-add origin-id and stuff on reflection
danielit's probably better if the irc transport does the right thing(tm) than letting each and every client figure it out
ziniddaniel: agreed, nobody said writing transport is simple
danielirc transport should also reassemble the message if they previously split it and stuff like that
danielbecause they know best if they did
SaltyBonesHm.
SaltyBonesOkay, are there any actual problems with the current state of three IDs except that we don't like having so many?
danielyes
danielread what i said before
SaltyBonesUh, assuming a well-behaved server?
danielyes
danielmy argumentation has nothing to do with servers
jonaswdaniel, IRC doesn’t even reflect
jonaswso the transport generates the reflections on its own
SaltyBonesOkay, can you please point out what you are referring to then?
jonaswbiboumi however decided to reflect the split version of the message, and there’s some argument to doing that
danielassume i sent: <message id="1"><body>hi</body><request/><origin-id="2"></message>
and then i will receive from conversations: <message><receipt id="2"></message>
zinidwho cares about IRC, really, are we designing a protocol for old nerds?
danielbut we are talking about two different things. the how should irc transports behave has noting to do with the problem i'm describing
danielthis applies to 1:1 chats as well
jonaswdaniel, yes, I don’t argue that
jonaswI’m just replying to your message from "13:49:15Z" because I was away from keyboard.
remkohas left
danielthe irc transport with the name i can not pronounce or remember does a few things that i don't like :-)
ziniddaniel: if we don't care about IRC then we probably don't need origin-id and thus there is no the problem you just described
danielthere are non transport mucs which also rewrite the id
danielzinid, if it weren't only for transports i wouldn't care
danielGe0rG, is that an issue to change the name to something i can remember?
danielor pronounce?
ziniddaniel: if they are abandoned, then I personally give zero fucks
Ge0rGdaniel: no, it's about maintaining IDs on reflection
Ge0rGzinid: everything in XMPP is abandoned. Now stop giving fucks.
danieli should probably write my own irc transport
edhelasbiboumi is not good ?
Ge0rGdaniel: you should just patch biboumis two or three warts.
danieli haven't used irc though ever since counterstrike 1.6 came out
zinidGe0rG: not everything, so I still have a few fucks to give
danielthere are a number of things i don't like that seem to be design decisions rather than bugs
andyhas joined
danielso i'm not sure if they even want me to change them
SaltyBonesdaniel, so regarding your example, what you are saying is that the read receipt might reference the message-id or the origin-id and it is not properly specified which?
zinidOk, whatever, so what do you guys think about muc subscriptions?
SaltyBonesOr are you getting at the fact that origin-id requires "by=" and is therefore sometimes not applicable?
daniel> daniel, so regarding your example, what you are saying is that the read receipt might reference the message-id or the origin-id and it is not properly specified which?
This
danielnot just read recepits but everything that references something
danielbut yes
jubalhhas joined
ziniddaniel: isn't there a place in the xep which says you should copy the message-id?
danielzinid, no.
zinidReally?
danielthat's what Ge0rG and I want to add to the XEP
danielthat's pretty much what the entire discussion is about :-)
zinidSo add it 😀
danieli can't without permission of the author
zinidNo shit?
SaltyBonesSo, there is some problem that I am still not aware of....
SaltyBonesFlow, why is the by attribute in the origin-id?
zinidWho's the author?
SaltyBonesThe one that causes the privacy problems...
KevNot entirely true, BTW, that it's impossible to do things without the author. But it's the path of least resistance.
danieli don't think there is a by attribute in the origin id
SaltyBonesAh, sorry that is only for stanza IDs. origin-id does not have by.
zinidPeter is the author
SaltyBonesThat might almost always be correct buy 0359 is Florian Schmaus
SaltyBonesThat might almost always be correct but 0359 is Florian Schmaus
zinid> In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message.
zinidAnd you want this SHOULD to be a MUST?
lskdjfhas joined
SaltyBoneszinid, what some people here want is that origin-id = message-id
SaltyBonesGe0rG, you had an objection to that in https://mail.jabber.org/pipermail/standards/2017-September/033415.html but I don't quite understand it. Why do you want to know if somebody creates strong message-id?
zinidSaltyBones: but the sender controls this itself, so what is a problem to set them equal?
danielzinid, we want wording that tells the client developer to do this
danielthere is no 'problem'
efrithas joined
Ge0rGSaltyBones: I thought it would matter, but it doesn't, because there always can be malicious entities
ziniddaniel: if they don't then they only harm themselves, I guess
Ge0rGzinid: no, they harm the other participants
zinidGe0rG: ah
SaltyBonesHow?
zinidYeah, how?
Ge0rGzinid: also, it's well possible that stanza ids are generated by the xmpp library, and origin ids by the client, causing a mismatch
Ge0rGBy making all message references break
Ge0rGWe had that above already.
SaltyBonesBefore we move to stanza-ids....
SaltyBonesThere is nothing wrong with requiring origin-id = message-id?
Martinhas left
zinidIf we require this then why origin-id is needed, wtf?
SaltyBoneszinid, it's possible that it was a mistake
SaltyBonesdaniel, does requiring origin-id = message-id actually solve your problem or are there cases when stanza-id might be used to refer to a message instead??
danielIt solves my problem
andyhas left
andyhas joined
SaltyBonesdaniel, wouldn't it be better to just mandate that clients always use the origin-id to avoid the problem of dealing with id-rewriting MUCs?
SaltyBonesI mean, certainly removing an unnecessary id would also be desirable but this might be a good intermediate step.
Martinhas joined
SaltyBonesWould everything be better if clients would generate proper stanza-ids?
SaltyBonesFor ...uh...some definition of proper that makes them UUIDish.
zinidthey should be strictly monotonically increasing, so we don't need XEP-0198
SaltyBonesAnd by "would everything be better" I specifically also mean, wouldn't that allow us to ditch the other IDs?
zinidand not UUIDs
jonaswzinid, "strictly monotonically increasing" is not gonna happen
zinidbecause?
SaltyBoneszinid, would increasing IDs really solve all the same problems as stream management? Seems unlikely?
jonaswzinid, also, increasing IDs have security implications
jonaswor rather: predictable IDs
zinidSaltyBones, it solves in data replication, but of course XMPP is too unique
zinidversion vectors are based on such ids
zinidjonasw, what security implications?
jubalhhas left
jonaswzinid, I think there were some IQ response injection attacks based on predictable IDs
jonasweven though in that case you probably already made the mistake of not verifying the sender of the response
jonaswerror injections would most likely work though because errors can come from entities different than the original recipient
zinidjonasw, this can be fixed by adding routing information
SaltyBonesjonasw, maybe this is too much of an assumption for all of XMPP but don't we have transport encryption?
zinidwe anyway need this functionality already
jonaswSaltyBones, that doesn’t stop me (jonas@zombofant.net) from sending an iq type="error" id="whateverIguessed" to="you" to break whatever you were doing
SaltyBoneszinid, I agree, if this is a problem I don't see why it cannot be exploited right now by somebody who randomly sees the message first
jonaswSaltyBones, if I can guess the ID, I can attack you from off-path
jonaswI can’t do that when I can’t guess the ID
jonaswif I’m on path, you’re right, everything is lost already in XMPP.
zinidbut if you cannot match incoming errors against requests you sent then you should really consider to change the job
jonaswzinid, how’d you match incoming errors against requests other than the ID?
jonaswyou can’t really use from, because as I said, it might come from an entity you didn’t know about yet
MattJjonasw, no?
zinidjonasw, you can use (from, ID) I think
MattJerrors come from the original recipient that you addressed
jonaswMattJ, even if an s2s error causes an error?
MattJYes
jonaswoh okay
MattJOtherwise it would be a nightmare
Dave Cridlandjonasw, There's a "by" attribute, if I remember right, that tells you the generator/reporter of the error.
Dave Cridlandhas left
SaltyBonesSo, I assume that if I run a h4xx0r server and try to send replies to messages that were not directed to me to some other server they will be discarded?
SaltyBonesAnd the same happens between client and server...?
MattJSaltyBones, by "replies", you mean error replies?
SaltyBonesWhatever magical interferring replies that jonasw was referring to :)
SaltyBonesyes, errors ;)
MattJFor that to work you would have to know the original sent message id, and the original sender's full JID
SaltyBonesBut if I did, I could?
MattJand then yes, you could send them whatever you wanted - it would be up to their client to match it up (or not) to one of its outgoing messages
SaltyBonesSo, the statement that predictable IDs would allow me to spoof responses remains correct?
MattJso as said above, the client should use (from, id) to identify error responses, not just the id
SaltyBonesBecause I cannot spoof "from"?
MattJCorrect
SaltyBonesYes, okay...
SaltyBonesThat's what I was looking for. :)
remkohas joined
MattJid "abc123" from userA@domainA is different from "abc123" from userB@domainB
SaltyBonesAnd servers only accept s2s with from=...@domainA if they know that the other server is in charge of domainA?
Dave CridlandSaltyBones, That's what they're supposed to do, yes.
remkohas left
SaltyBones^^
MattJSaltyBones, yes, they do
Dave CridlandMattJ, No, they don't, but I love your optimism.
MattJIf they don't, it's a bad bug or not an XMPP server
Dave CridlandSaltyBones, So Metre (my S2S proxy mad thing) does this very strictly, and as a result I can't join this chatroom from my personal server.
Dave CridlandSaltyBones, Not sure if MattJ is saying that's a bad bug in this server, or if he's saying it's not an XMPP server. :-)
MattJDave Cridland, for what reason?
jubalhhas left
andyhas left
SaltyBonesDave Cridland, so which messages do you get that don't pass?
Alexhas left
SaltyBonesBunneh, version xmpp.org
BunnehSaltyBones: xmpp.org is running Prosody version 0.9.12 on Linux
Dave CridlandMattJ, It's sending a response down the stream obtained by reversing the stream to/from, and not by reversing the stanza to/from. I forget the details, Zash knows.
Dave CridlandMattJ, I don't know if Prosody would accept that or not. Metre doesn't, Openfire does (but because it knows it's multiplexed on the outbound, so weirdness.)
Dave CridlandMattJ, For maximum fun, Openfire used to do similar "implicit" auth on outbound, but I stopped that as from 4.2.0.
MattJI don't really understand, but maybe Zash will enlighten me
Dave CridlandMattJ, Metre sends traffic for d.c.n -> muc.xmpp.org over a stream for d.c.n -> xmpp.org (after adding that domain via dialback).
ZashHow far back should I read to have any idea what you are talking about?
SaltyBones15:58 should suffice
MattJSaltyBones, and a time machine
Dave CridlandMattJ, Prosody (0.9) responds to the traffic on the reverse stream, xmpp.org -> d.c.n - which it hasn't requested authorization for yet.
SaltyBonesDo you mean a timezone machine or a MAM machine?
Alexhas left
ZashNo MAM here
Dave CridlandSaltyBones, For your amusement and mild confusion, XMPP authorizes streams by a 3-tuple of (from-domain, to-domain, direction).
ZashPage up button tho
Dave CridlandSaltyBones, Well. One or more of those 3-tuples anyway.
MattJDave Cridland, who hasn't requested authorization for what? You mean Prosody connects to d.c.n as 'xmpp.org' and sends stanzas from 'muc.xmpp.org'?
Dave CridlandMattJ, Yup, that.
dwdhas joined
ZashThe thing
Dave CridlandMattJ, Like this: DEBUG 2018-02-12T15:14:35 /home/dwd/src/Metre/src/xmlstream.cc:95 : NS296914 - G
ot [399] : <?xml version='1.0'?><stream:stream xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='xmpp.org' t
o='dave.cridland.net' xml:lang='en' xmlns='jabber:server'><iq id='472-452048' ty
pe='error' to='dave.cridland.net' from='xsf@muc.xmpp.org/tim@boese-ban.de'><erro
r type='cancel'><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></e
rror></iq>
dwdThis time I'm joined. Timing, I guess.
ZashUh, what was the thing with that again?
Dave CridlandZash, The bug itself? Responding to inbound traffic on a multiplexed stream by reversing the wrong domain pair.
MattJdwd, I don't see how timing would play a part
ZashDave Cridland: Do you remember where we discussed this?
Dave CridlandMattJ, I think whether I can join is dependent on what streams are open, which is dependent on the session lifetime and activity.
Dave CridlandMattJ, Not timing as in a race condition, mind.
Dave CridlandZash, Erm. 1:1 messages, I think, until we figured out it definitely wasn't a security issue.
Dave CridlandZash, Possibly some discussion in jdev.
dwdFWIW, I have to put in something similar to an implicit auth for X2X, anyway. So this may provide a workaround.
Dave CridlandHolger, Can you download NetBSD yet, or is it still only available on tape?
zinidHolger, cool stuff btw
SamWhitedMore importantly, once I download it can I run it on any machines made after 1995? (this is always the problem I had trying to run NetBSD; a few of the ops people at work run it, but they all use *very* old machines)
Dave Cridlandgets prepared to explain "tape" to the younger readers.
Dave CridlandSamWhited, Sure! It runs pretty well even modern machines like the Amiga 4000.
nycohas left
Dave Cridland(Sorry, that was 1993).
SamWhitedExactly.
HolgerWell yes it's about as dead as XMPP :-P
SamWhitedI would like to use at *least* a P3.
HolgerBut it always worked okay-ish for me on non-recent ThinkPads.
HolgerI no longer do that though.
Holgercpu0 at mainbus0 apid 0: Intel(R) Core(TM) i3-2120T CPU
Holger... is the one box I still run NetBSD on.
ZashUh, was NetBSD the one being difficult, or OpenBSD?
HolgerDifficult?
SamWhitedActually, jokes aside, that might be a nice thing to do with my broken old thinkpad; doesn't work very well as a laptop anymore, but it could be a {Free,Net,Open}BSD or Illumos "desktop".
HolgerZash: Isn't all computers difficult except for Apple?
SamWhitedThis is true… ⤴
Dave Cridlandhas left
ZashEt Apple, Holger
Dave CridlandI find Apple incomprehensibly difficult to use, I must admit.
Dave CridlandI've yet to figure out how to go up a directory consistently in file dialogs.
Kevcd ..
KevHappy to help.
HolgerManaging FreeBSD feels more or less like Debian to me, the two others feel a bit more basic but not really harder to use. All dead simple compared to the dances you had to go through when partitioning hard disks or getting X11 to run 20 years ago with any Linux or BSD.
Dave CridlandHolger, Ah, X11. Kids these days don't know they're born.
Dave CridlandKev, Don't get me started on the antiquated command line tools Apple foists upon you.
remkohas joined
HolgerYes, we're horribly old.
Dave CridlandHolger, We're very experienced. I'm sure that's what you meant.
ZashI'm sure wayland will bring back the good old times for those who miss configuring Xorg
HolgerPrecisely.
SamWhitedThe only thing I want out of a machine is to sync an old ipod without Rhythmbox crashing…
Dave CridlandSamWhited, Rhythmbox never crashes.
Dave CridlandSamWhited, At that speed it's called "parking".
SamWhitedRhythmbox is one of those people who parallel parks by backing up until they hit the car behind them, then driving forward until they hit the car in front.
efrithas left
jubalhhas joined
Alexhas joined
SaltyBonesSo, why is it that a client cannot create the stanza-id?
SaltyBonesIs this a thing about malicious clients or what's going on there?
Dave Cridlandhas left
jonaswSaltyBones, no, unaware clients are sufficient; colliding IDs would lead to interesting issues with MAM
SaltyBonesjonasw, but if the client is only unaware the server could just return an error informing the client that this ID has been used.
Dave CridlandSaltyBones, But we could use, say, stream-id + attribute-id to form a stable, non-colliding reference identifier.
jonaswSaltyBones, that’d be annoying to handle in the client, and the server would need an O(1) (or similar) way to determine that the ID has been used already...
SaltyBonesYeah, or we could hash things and god knows what else...it seems very solvable...
Dave CridlandSaltyBones, I mean, unless the client isn';t generating unique ids within its stream, in which case it's presumably not going to be fixed to use some other identifier.
jonaswDave Cridland, stream id + sm-counter?
jonaswthat’s verifiable by the server
jonaswand predictable for both
Dave Cridlandjonasw, True. But I think we had some ideas on predictability outside the stream?
SaltyBonesthrow a hash on top to avoid privacy issues, done
SaltyBonesDave Cridland, I thought we dicussed those into oblivion earlier? :)
Dave Cridlandjonasw, An HMAC is two nested hashed with concats and masks, yes.
SaltyBonesOkay, so we only disagree on our definition of nearly. ;)
Dave Cridlandjonasw, But the security properties are distinct.
jonaswDave Cridland, I don’t argue that
jonasw(and I’m aware)
SaltyBonesAnyway, the suggestion of HMAC(key=stream-id, msg=sm-counter) seems good, doesn't it?
Dave CridlandIn any case, given a stanza with a known id on a given stream, we clearly want to be able to predict the MAM id.
SaltyBonesI mean, I am also fine with SHA-*(stream-id || counter-sm)
SaltyBonesDave Cridland, but mam-id = stanza-id which is what I am proposing to set to this...
Dave CridlandQuestion is, do we think the MAM id is likely to become public, and if so, can someone relatively easily figure out the next (or previous) value, and then do Something Bad?
SaltyBonesDave Cridland, that might be the question bit if it only costs us a hash per message to not answer it might also not be...
SaltyBonesDave Cridland, that might be the question but if it only costs us a hash per message to not answer it might also not be...
SaltyBonesDave Cridland, that might be the question but if it only costs us a hash per message to not answer it, it might also not be...
Dave CridlandWhat I'm wondering, you see, is whether we give clients an algorithm to generate attribute-id and then let them signal to the server that they're going to use globally-unique attribute-ids and the server is allowed to call them out if they don't.
jonaswDave Cridland, okay, right, this is about the MAM ID. this *probably* doesn’t matter, but if the goal is to consolidate all IDs at some point, choosing a way where the ID can become public is safer
zinidhas left
Dave Cridlandjonasw, That's roughly my thought, yes.
jonaswand at that point, HMAC(…) seems like a sane choice.
Dave Cridlandjonasw, Well, that and "But we *HAVE* stanza ids - right there in the stanza!"
KevHow would the server know that they didn't use a globally unique id?
SaltyBonesKev, if the server can simply re-run the generation algorithm and compare results..?
jonaswKev, if the ID doesn’t follow the algorithm for a globally (predictable, for the server and client only) unique ID
Dave CridlandKev, Well, it'd know if they used no id at all, and if it saw a collision within a stream.
KevIf we only cared about collisions within a stream, we could trivially solve all issues already.
SaltyBonesAnd that is how you can tell that Kev is a VIP
SaltyBoneswhen he says something three people reply!
Dave CridlandKev, Well, we care about collisions for a user's account for MAM, and no further.
KevBut having a useful id to refer to a message would be jolly useful, and I don't see how we can get there yet.
SaltyBonesOkay, so you're saying when two servers federate and you assume one of them is malicious how can the other make sure he doesn't get duplicate IDs?
KevOr non-malicious server with a malicious client.
Dave CridlandSaltyBones, Do they care? ANd if not, should they?
jonaswSaltyBones, you don’t use other servers stanza-ids in your own MAM
SaltyBonesWell, the malicious client would be detected by the server.
Kevjonasw: Bloody useful if you could, though, no?
KevSaltyBones: How would the server know it's malicious, if it doesn't know all globally generated ids?
Alexhas left
SaltyBonesKev, it can simply check if the client generates their IDs correctly...
Dave CridlandKev, Again, why would a server care?
KevWithout exploding the size of IDs, at least.
jonasw(we should mandate the use of shakespeare-inspired adjectives in each bloody sentence in this room, by the way)
jonaswKev, how would it be useful?
KevI'd like to send a reference to a stanza, where the reference makes sense in my archive, the MUC/MIX archive, and the user's archive.
Dave Cridlandjonasw, I don't think "bloody" is Shakespeare. "Submarine" is, though, as far as I remember.
SaltyBonesKev, you simply make it a hash or hmac of something that both the client and the server know and the server can check the calculation.
Kev"simply" :)
SaltyBonesKev, but doesn't that only involve you, the muc/mix server and $other_client? i.e. only one server...?
Dave CridlandKev, Is the (from, id) attributes of the stanza sufficient? If not, why?
ZashIf this is for MAM purposes, then I will cry if I can't stick some time based bits into the ID
KevDave Cridland: No, because the from gets rewritten.
Dave CridlandKev, When?
SaltyBonesZash, what?
KevIn a MUC or a MIX.
ZashMy MAM ids are basically yyyy-mm-dd-random
jonaswKev, those are different use-cases I think.
Kevjonasw: If we cherry-pick the trivial use cases, it's going to be trivial to solve them :)
jonaswKev, this is where origin-id makes more sense. It is generated by the client. If the client doesn’t ensure that there’s enough entropy in there, references to their message won’t work.
SaltyBonesZash, and this is important because?
Dave CridlandKev, Ah, so given a message from a MUC fanout, do you want to be able to identify the originating id? I'm not actually sure you always want to allow that.
Alexhas joined
jubalhhas joined
SaltyBonesI still don't get it. Why does from get rewritten?
SaltyBonesAnd what does that have to do with anything? :D
jonaswSaltyBones, when you send a message from saltybones@yourdomain.example/client-resource to this MUC, we see the message from xsf@muc.xmpp.org/SaltyBones
jonaswso the from is being rewritten.
jonaswand if references are based on (from, id) pairs, you can’t use the same reference we all can use for your message
jonasw(simplified, of course we could still refer to the reflection of the message, but that would break down with MIX, too, I think)
Dave Cridlandhas left
Kevjonasw: Well, no, because if you can fake someone else's id, suddenly you can maliciously change the target of a reference.
jonaswKev, good point. so we indeed need something like (from, id) :(
SaltyBonesWait what?
zinidlol
SaltyBonesHow can you now fake stuff again?
jonaswbut given that all our fanouts and from-rewriting things do actually do reflections, I’m not sure if that’s so bad, Kev?
jonaswyour local archive woudl still be able to resolve everything
Kevjonasw: Well, it enforces a round-trip before you can refer to or correct anything, which isn't ideal.
jonaswKev, you normally know the "from" you’ll be having.
jonaswand since you set the origin-id yourself, you already know everything you need
jonasw(meh, races with server-enforced nickname changes in MUC)
KevPoint.
jonasw(but I guess those will be rare enough for us not to care)
SaltyBoneshalp! :(
Dave Cridlandhas left
KevSaltyBones: Because there are potentially malicious entities.
tim@boese-ban.dehas left
danielhas left
SaltyBonesAre these only clients or servers as well?
Kevjonasw: Still doesn't help where a user generates the same id twice, I think, and you're left with ambiguous references/corrections/whatever.
KevSaltyBones: Both.
SaltyBonesSo why do you connect to a malicious server and expect things to work?
SaltyBonesMaybe that's not a good approach.
jonaswKev, that’s not an issue. put 256 bits of entropy in there and you are officially allowed to not care
KevAh, if you have a mechanism for identifying malicious intent on the Internet, you could be a very famous person.
jonaswKev, and if we want to have defined behaviour in that case, always assume the most-recent message
ralphmhas left
Kevjonasw: That only works for accidents, rather than manipulation, no?
marchas left
SaltyBonesKev, but you cannot manipulate as long as the server is checking.
jonaswKev, indeed
jonaswbut if you manipulate your own origin-ids, it’s your own fault?
SaltyBonesOf course if we have malicious servers now a bit more work is required. :)
KevAnd I'm concerned that 'most recent' falls apart if you can manage different people receiving different subsets.
jonaswcan one inflict harm by producing duplicate origin-ids?
jonaswI’m not convinced that this is actually an issue.
KevMost likely.
KevIf I can cause the 'wrong' message to get corrected.
jonaswmaybe with something like Reactions based on (from, origin-id) references.
KevOr a like to apply to the wrong message.
KevIf I can manipulate you into liking a Godwin instead of something sensible, that's not ideal.
andyhas joined
jonaswmeh
SaltyBonesBut messages aren't authenticated anyway, if you are a malicious server you can claim to have received whatever likes from me...
jonaswKev, then the only way is a MUC/MIX stanza ID generated by the MUC/MIX and waiting for a round-trip before references can be done.
KevSaltyBones: Other way around.
jonaswSaltyBones, all it needs for now is a malicious client though
jonaswSaltyBones, or a malicious client+server pair if we do the hmac-stanza-id thing for origin-id
jonaswI can still run my own server and make it fake origin-ids
danielhas left
andyhas left
andyhas joined
zinidyour own malicious server?
jonaswKev, I’d however argue that actively, from a client/own server side, make participants in a MUC/MIX receive only parts of the conversation would be rather trikcy
jonaswand targeted parts even
jonaswand that without them suspecting that things are broken in funny ways and thus not trusting the system anymore
Kevjonasw: Ah, that's ok then, no exploits have ever involved doing anything tricky :)
jonaswKev, I see your point, but I’m not sure this is actually something which is reasonably exploitable.
jonaswbut yes
jonaswunless we let the ID be generated by the fanout service, there’s no way to be sure I’m afraid
jonaswI mean, I don’t have an issue with that, I’m fine with that even.
KevYes. I don't see a way of solving this, which was why I brushed it under the carpet at the Summit.
jonaswcomplicates things though
Guushas joined
jjrhhas left
marchas left
jonaswKev, I’m having a really hard time constructing a successful attack which wouldn’t be seen by the victim in the MUC case
jonasweven when I omit arbitrary messages
jonaswto only some participants
jonasw(which would be really really tricky to achieve targetedly I think)
jonaswah, now I have it
jonaswthis is the scenario:
1. user A, "bad statement", origin-id=1
2. user A, "good statement", origin-id=1
3. user B, like (from=user A, origin-id=1)
if (2) isn’t seen by all users, they see user B liking "bad statement" instead of "good statement"
tuxhas joined
jonaswwith an arbitrary amount of messages between (2) and (3), it is also not too difficult to make people not see (2) in a MAM-less MUC.
KevIndeed.
Dave Cridlandhas left
jonaswI don’t think there’s a way unless the MUC does things there
jonasw(i.e. if the MUC generates the ID?)
SaltyBonesBut, all it requires to prevent that is for the MUC to check that the ID is unique just like the assumed-non-malicious server did in our previous discussionn...
jonasw(i.e. if the MUC generates the ID)
jonaswSaltyBones, but that is a rather expensive check to do
jonaswyou need to record IDs for all eternity, or have a defined way to generate the ID which can be executed by clients
jonaswthe latter would be tremendously tricky to get to work synchronously
jonaswbut possible...
SaltyBonesWhich is a little more tricky because there is no obvious common "secret" like the stream-id but a simple Hash("counter") would do
jonaswsomething like hash(message-counter || presence-id), where presence-id is an ID assigned to the client on join
SaltyBonesKev, not that in this case I used the word simple again but I was totally lying...
SaltyBonesKev, note that in this case I used the word simple again but I was totally lying...
jonaswhash counter doesn’t really work with multi-session nicks I think, it would lead to collisions or races
SaltyBonesjonasw, yeah it was just to get the idea. Indeed you would at least need some salt.
SaltyBonesBut if the server gives you the salt on join and you use that to generate the IDs it should be good again.
jonaswthat would be verifable by the MUC and the MUC would drop stanzas which do not adhere to this schema
jonasw(or rather, reject)
SaltyBonesand since the counter can be per-muc there is no issue with having it
jonaswper client even
SaltyBonesI think :p
jonaswKev, ^
SaltyBoneswell, yes per client and per muc
SaltyBonesjust saying it doesn't seem to be a privacy issue
jonaswSaltyBones, yeah
remkohas joined
jonaswso origin-id = one-way-function(presence-id, message-counter), where presence-id is assigned on MUC join
andyhas left
jonaswonly need to define what happens when message-counter wraps around or becomes large or something
jonasw(same thing for SM by the way, SM has wraparound semantics)
efrithas joined
SaltyBonesO_o
SaltyBonesY U SEND SO MANY MESSAGES!?!!
ralphmhas joined
jonaswSaltyBones, itym "y u have so long sessions"
andyhas joined
SaltyBonesstill, if this is defined somewhere we can probably renegotiate the salt at that point...
jonaswwhile wrapping around a 64bit counter in a single session is sure challenging, we need to be prepared if this is to be solid :)
jonaswyeah
Marandahas joined
zinidI hear counter?
zinidsorry, I don't track the discussion
jonaswzinid, I’m not going to repeat everything you can read in the backlog :)
zinidas you wish
zinidnot that I care
SaltyBonescounter works in this case because you can restart counting when rejoining the muc
zinidwhatever you will end up will be shit anyways, so
Marandahas left
zinidyou already created 4 fucking ids: stanza-id, origin-id, attribute-id and SM id
zinidmaybe it's time to stop and think?
jonaswwhat is an sm ID?
zinidh
jonaswright
jonaswzinid, all of this is about reducing the number of IDs, so I thnik this is kinda what we’re doing?
zinidjonasw, from what I see you want to add yet another counter
jonaswzinid, to generate origin-ids, yes
jonaswfor MUCs and MIXes
jonaswto make them verifiable by the service
jonaswzinid, or rather, we’re replacing origin-id by some one-way-function(counter)
zinidhow this will cover sm id?
waqashas joined
SaltyBonesWe haven't discussed sm-id, yet. Only the other three.
SaltyBonesI actually have no clue what sm-id is. :)
zinidSaltyBones, then I need to wait while you recognize the problem 😉
SaltyBoneszinid, so reducing 4 -> 2 is not enough, eh? :p
jonaswzinid, sm-id stays, but stanza-id (and attribute-id) could potentially become one-way-function(stream-id, sm-id)
zinid2 is enough, however I think first should be counter and second should be routing information, and not an ID
jonaswstanza-id being used for the archive only, origin-id being used throughout the network together with the sender address for refernecing a specific message
lovetoxhas joined
zinidwhat ID will be used to sync?
ralphmhas joined
zinidwith SM IDs you just create a pointless queue in c2s state
Ge0rGhas left
SaltyBonesOkay, I think we are trying to solve a problem that is very orthogonal to stream management. But we have only discussed this a bit and it might very well not work even for what we want it to do.
zinidSaltyBones, I don't think SM should be separated from archive
zinidit's pointless
SaltyBonesWhy?
jonaswzinid, stanza-id is used for ysnc
jonasw(for MAM sync that is)
zinidSaltyBones, because why you need this separation?
zinidSaltyBones, you keep messages in MAM and then put them in c2s SM queue
zinidwhy can't you just inc(counter), store in MAM and send via c2s?
SaltyBonesWhy are you asking me that? I am 100 % sure that you know more about SM than I do!
zinidwhat I know about SM is that I need to maintain stupid queues inside c2s processes, which sucks as hell
zinideven though a client can request those messages via MAM
zinidif you receive an ID out of order, you just reconnect and ask everything started from the ID you received
zinidand server will send you this from archive
zinidand vice versa
SaltyBonesBut SM-IDs are per-stream not per-message, right?
andyhas left
SaltyBonesAt least that's what it looks like in https://xmpp.org/extensions/xep-0198.html
zinidwhen you connect a server, you provide last seen ID and it will resend you everyting what's greater than this ID
zinidSaltyBones, yes, they are totally separated instances
SamWhitedWhat if the thing you missed was an IQ or a presence that isn't stored in MAM?
SamWhitedIf you temporarily disconnect and miss something, SM acks allow you to find out. Doesn't help as much if it only covers messages.
zinidSamWhited, I think we can drop them
ralphmhas joined
zinidSamWhited, we already don't care about IQs with Push, so why would we start care?
zinidtry to make jingle call when I'm in "push" mode
SamWhitedDoes that not work? That does seem like something we need to care about to me
zinidSamWhited, but we don't and we cant with push stuff
jonaswshouldn’t an IQ trigger a push? :-O
zinidSamWhited, what if I want to receive your software version and you're in push mode?
SamWhitedThat seems like a problem that needs fixing then, not an example of something being done right that we should copy.
Steve Killehas left
zinidanyway, you can keep IQs in MAM if you prefer
zinidyou need to keep subscription requests for sure there
zinidwe keep them already, but in a separate database due to historic reasons only
Martinhas left
andyhas joined
Steve Killehas joined
jonaswIQs (which are inherent request-response, with exactly one response) in MAM sounds like a terrible idea.
SamWhitedyah, now you have to try and figure out which IQs are time sensitive, which are important to store, etc. it seems like a comlicated way to work around having a stanza counter.
zinidSamWhited, but you have to decide now too: for example, after 5 minutes of inactivity (by default) a server just bounce all IQs from SM queue
zinid*bounces
SamWhitedI'm not saying it's perfect, just that this doesn't seem like a good fix.
zinida fix? the behaviour is the same
SaltyBoneshas left
zinidbut we let a client to decide which IQ to reply
SamWhitedExcept now you have to store all stanzas in MAM, or not store some stanzas and risk those being the ones that are dropped and you don't know you missed something. The point of SM is to make sure you know if you lose something, which is often important.
andyhas left
ziniddo you really want to loose incoming call?
zinidthat's how it works now: if somebody calls you and you're not connected you loose any track
SamWhitedAs I said, I'm not claiming that the current solution is good; just that this makes it worse.
zinidno, it makes it better
zinidyou just need to define what to store and what not, well, it's too much to redesign, yes
SamWhitedIf you don't store everything you now lose the ability to detect connection drops though
zinidsigh
Dave Cridlandhas left
Guushas left
Guushas joined
zinidnot sure how will you address missing call though
zinidwith your approach
SamWhitedI do not have an approach; I agree that is a problem that needs solving though.
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBonesIt seems like we need storage for management messages and storage for actual messages. I don't see why these should be mixed up.
Guushas left
rionhas left
Dave Cridlandhas left
Guushas joined
remkohas joined
zinidwe need to decide what to store and what not
Dave Cridlandhas left
SaltyBoneshm..that distinction was wrong, yeah
SaltyBonesthere should be a storage until delivered and an optional long term storage
Dave Cridlandhas left
SaltyBonesusers might not even want mam :p
zinidif you don't want mam then just lose messages
SaltyBonesOkay, let me rephrase, some users might not want long-term storage of messages...
zinidnot sure why this should be specific to any approach
SaltyBonesBecause I think that's what MAM is intended for and that's why using it for all messages as you suggest is strange and might have unexpected results if people built it under the assumption that it is for long term storage...
brahas left
brahas joined
zinidservers can drop MAM archives on reconnect for example, what's the problem?
SaltyBonesOkay...
zinidor later, when it's delivered
SaltyBonesthis is just me confusing MAM and the other thing again...
SaltyBonesfor the one-millionth time...
Ge0rGWhat if I want my messages both on my pc and my mobile? I can't just drop MAM when my pc is online
zinidyou can if everything is delivered
zinidanyway, what you are trying to say is a partial replication, and this problem is very hard to resolve
SaltyBoneswhat is the other thing again, server side archiving?
ralphmhas joined
SaltyBoneszinid, does MAM know if everything was delivered?
Seve/SouLhas left
Ge0rGhad a very concerning realization about guessable IDs and packet filters in smack earlier today.
zinidSaltyBones, well, no, I think you cannot know that in general case
SaltyBoneszinid, but that is what SM does, right?
zinidSaltyBones, well, if you introduce acks, then yes
SaltyBonesHm.... :)
HolgerAll this is orthogonal to the question whether having two separate stanza/message queues is sane. I agree with zinid that it isn't.
ZashTwo whatnow
Ge0rGI'm saying for many years now that we need to replace 0184, 0198, 0280 and 0313 with one single proper message syncing thing.
HolgerSM is already mostly just an optimization, and I think we should fix the remaining issues to make stream management superfluous.
SaltyBonesI just want to point out that this is orthogonal to our earlier discussion about IDs :)
zinidSaltyBones, I said "no" in general case because we have Bysantine General Problem, it's unresolvable, what we can gurarantee is sequential consistency
Dave Cridlandhas left
Ge0rGSaltyBones: please show your ID before being allowed into this room :P
Tobiashas joined
SaltyBonesHolger, does anybody already know what those issues are?
danielhas left
Guushas left
Guushas joined
ZashGe0rG: Kidnap some server devs and lock yourself in a room until that one single proper message syncing thing to rule them all is properly implemented and XEP'd
HolgerSaltyBones: Syncing of outgoing messages (in a sane way) and maybe avoiding some round trips during session startup.
zinidZash, and watch them die 😉
Ge0rGZash: I'll lock you and zinid up in that room, and watch the live stream
SaltyBonesHolger, so, can we just turn off stream management and leave MAM and see what happens to find out?
HolgerSure you can :-)
SaltyBonesOr do you think fixing up MAM is a bad idea and something new is required?
ZashSaltyBones: That's what I did, actually. Haven't died from SM-lessness yet.
HolgerSaltyBones: I think you can already implement proper sync with MAM as-is. But something new is required to let clients implement this in a sane way, without having to de-duplicate and whatnot.
zinidthat's my point: what we need is to store messages and some other restricted stuff and call it a day
SaltyBonesHolger, so would unique message IDs solve this?
SaltyBonesI mean, at least de-duplication would be reasonably easy then, I guess.
jjrhhas left
SaltyBonesOf course some sort of counter makes more sense in this case...
ZashSM has counters. MAM has server-issued, guarante to be unique message ids.
ralphmhas joined
SaltyBonesWhy are IDs not a counter?
HolgerNot sure what sort of uniqueness we need to solve what problem. Didn't read the backlog, sorry :-) The thing missing for proper sync of outgoing messages is an algorithm to compute the MAM IDs of outgoing messages.
SaltyBonesI mean the MAM-IDs....or is that the same as the stanza-ids?
Holger(Sorry, typed this before reading the last few messages.)
zinidZash, now answer the question "get me last messages I didn't receive" with current SM and MAM approach 😉
SaltyBonesHolger, what do you mean by outgoing? Messages that we sent?
HolgerYes.
zinidif you say "time", then no
Zashzinid: query after = id of last message I saw
SaltyBonesOkay, that should be solved by the hash idea....if it works :p
Zashcry over outgoing messages sent after that
HolgerSamWhited: I need to know their IDs so I can tell the server "give me all messages since $id".
SaltyBonesBut indeed if we want to query MAM by a "point in time" or "counter" unique IDs are not really the best thing :)
remkohas joined
SaltyBonesHolger, but then the server still has to search the MAM archive for that ID and give you everything after it....
zinidZash, define after in distributed system 😉
SaltyBonesSo a counter would be much better.
HolgerSaltyBones: Sure?
Zashzinid: MAM archive ids on incoming messages
SaltyBonesRight?
Zashzinid: after is a MAM term
zinidZash, but you need some ordering
pep.has left
Zashzinid: huh
Zashzinid: XMPP streams are ordered
zinidyes, but you need to maintain a timestamp index in the database
ZashYou've lost me
Dave Cridlandhas left
Guushas left
Guushas joined
zinidwell, you're probably right that if we assume timestamp ordering then we don't need counters and SM at all
ZashHuh?
ZashIn a MAM query, 'after' is a field that carries a MAM archive ID
zinidso, what's the ordering? 🙂
andyhas joined
zinidID+1?
zinidfrom what I understand you use timestamp+id, which means time ordering
ZashOrdering?
ZashAs I said, you lost me. I have no idea what any of us are talking about anymore.
zinidok
vanitasvitaehas left
lskdjfhas left
Guushas left
Tobiashas joined
Dave Cridlandhas left
remkohas joined
la|r|mahas joined
danielhas left
rionhas joined
Dave Cridlandhas left
suzyohas joined
Dave Cridlandhas left
andyhas left
ralphmhas joined
Dave Cridlandhas left
rionhas left
Syndacehas left
Syndacehas joined
Dave Cridlandhas left
blablahas left
blablahas joined
remkohas joined
Dave Cridlandhas left
ralphmhas joined
Dave Cridlandhas left
Ge0rGhttps://summerofcode.withgoogle.com/organizations/?sp-page=5 no xsf?
zinidBEAM community is there 😛
andyhas joined
jjrhhas left
remkohas joined
ralphmhas joined
andyhas left
moparisthebestSaltyBones: like 98% of what you were talking about is here https://github.com/moparisthebest/xmpp-ircd
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
moparisthebestBasically it works if IRC users don't want nickserv or chanserv but they do and I never got back to it :)
SaltyBonesmoparisthebest, you mean of a way to connect to a muc using the irc protocol?
moparisthebestYes
moparisthebestRunning that makes a muc look like an IRC server to an IRC client
Dave Cridlandhas left
SaltyBonesI'm pretty sure nobody wants that. At least I don't! :D
SaltyBonesBut I think it might provide an excuse for people who have to convince irc users ;)
Dave Cridlandhas left
moparisthebestSaltyBones: yesterday you said
moparisthebestHm...maybe the transport should be the other way round.
Offer an IRC server that connects to MUCs.
moparisthebestThat's what I was referring to
vanitasvitaeIgnite didnt make it into GSoC
vanitasvitae:(
jubalhhas joined
Dave Cridlandhas left
danielhas left
jubalhhas left
jubalhhas joined
SaltyBonesmoparisthebest, I know, I said that regarding the discussion of the KDE folks looking for an IM solution
andyhas joined
Flow`> * Ge0rG had a very concerning realization about guessable IDs and packet filters in smack earlier today
Care to share?
marchas joined
jubalhhas left
FlowOr is it just something in the ancient smack library yaxim uses?
Dave Cridlandhas left
remkohas joined
moparisthebestSaltyBones, right so they could use a MUC, but also have an IRC server that IRC users could use
Dave Cridlandmoparisthebest, I like this, BTW.
moparisthebestand everyone would end up in the same place, but it'd be a muc
Dave Cridlandmoparisthebest, Is the GPLv3 your addition or from telepaatti?
ralphmhas joined
lskdjfhas joined
Dave CridlandAnyone know what servers support XEP-0288 these days?
Dave CridlandDoes this Prosody instance, for example?
moparisthebestDave Cridland, looks like the original telepaatti is gone, but GPLv3 goes back to at least the next fork looks like
andyhas left
andyhas joined
moparisthebesthonestly I kind of abandoned it because I like rust so much more than python nowadays but can't be asked to rewrite everything yet haha :)
moparisthebestI still run an IRC server I would love to rm -rf
SamWhited> I need to know their IDs so I can tell the server "give me all messages since $id".
I know, apparently I wasn't clear about something, sorry. I'm not suggesting we get rid of MAM or leave everything exactly as it is today, just that MAM doesn't cover some important parts of SM and probably can't be made to cover it without significant downsides.
Ge0rGFlow: it's affecting the old smack for sure, I'll have a look into smack 4 and let you know
SamWhited(sorry for the long delay, got pulled into a meeting and then was AFK for a bit)
Dave Cridlandgreps his logs
Dave Cridlandhas left
Dave CridlandSo there's actually only one server I talk to that does bidi. That's scary.
Dave Cridlandhas left
moparisthebesthas left
Dave Cridlandhas left
winfriedhas left
FlowGe0rG, let me know if you didn't just re-discover CVE-2014-0364
Dave Cridlandhas left
Syndacehas left
Syndacehas joined
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGFlow: it's related but different
ZashDave Cridland: Is it mine? :)
marchas left
Dave CridlandZash, No, Lance's. Although actually grep might have gone into Annoying Binary Mode.
SaltyBones-I ?
Dave Cridlandhas left
Dave Cridland-a, but yeah.
Dave Cridlandhas left
Syndacehas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave CridlandOK, so that's actually lots of servers doing bidi. Happy bunny, now. I've been putting the support into Metre.
Dave CridlandZash, Looks like it's PSYC and Prosody.
ZashProsody doesn't do it out of the box, you need to go a bit out of your way to install a community module.
Dave Cridlandhas left
Dave CridlandReally? Quite a few people have, then.
Dave Cridlandhas left
ZashDave Cridland: Question is, how much self-selection bias is there among people that have you in their roster? :)
Dave CridlandZash, Lots.
ralphmhas joined
remkohas joined
Dave Cridlandhas left
Dave Cridlandhas left
winfriedhas joined
winfriedhas joined
jubalhhas left
andyhas left
blablahas left
danielhas left
danielhas left
blablahas joined
moparisthebesthas joined
Dave Cridlandhas left
jubalhhas left
remkohas joined
Dave Cridlandhas left
zinidhas left
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
Alexhas left
Dave Cridlandhas left
Dave Cridlandhas left
remkohas joined
brahas left
brahas joined
danielhas joined
SamWhitedhas left
Alexhas joined
marchas joined
Tobiashas joined
Tobiashas joined
Dave Cridlandhas left
remkohas joined
brahas left
brahas joined
danielhas left
dwdhas joined
dwdhas joined
brahas left
brahas joined
danielhas joined
Dave Cridland.
Zash,
Dave Cridlandhas left
moparisthebesthas left
andyhas joined
KevM-Link does bidi, but we disabled it because of bug reports from Prosody about us not accepting stanzas down the right streams. Some of which I'm starting to question :)
Dave Cridland:-)
mimi89999has joined
Dave Cridlandhas left
Dave Cridlandhas left
brahas left
brahas joined
Kevhas left
moparisthebesthas joined
remkohas joined
brahas left
brahas joined
tuxhas left
jubalhhas left
pep.has left
moparisthebesthas joined
vanitasvitaehas left
Dave Cridlandhas left
dwdhas joined
blablahas left
tuxhas left
marchas left
SaltyBoneshas left
andyhas left
remkohas joined
vanitasvitaehas left
danielhas left
dwdSo, Metre now does Bidi.
danielhas joined
marchas left
lumihas left
dwdOK, this is weird. Metre is successfully negotiating Bidi with various Prosody servers. OK, great. But absolutely nothing ever tries to negotiate bidi with it, despite it offering the feature.
XSF Discussion - 2018-02-12