zinidjonas’, hey, I have sent you the protoXEP, I know you're busy, but maybe you will find some time to accept it for the upcoming agenda
debaclehas joined
ralphmhas left
ralphmhas joined
contrapunctushas left
contrapunctushas joined
igoosehas left
igoosehas joined
alacerhas left
contrapunctushas left
Kevhas left
contrapunctushas joined
lskdjfhas joined
Kevhas joined
ralphmhas left
ralphmhas joined
jonas’zinid, thanks for the hint
contrapunctushas left
contrapunctushas joined
andrey.ghas joined
andrey.ghas left
contrapunctushas left
contrapunctushas joined
contrapunctushas left
contrapunctushas joined
contrapunctushas left
contrapunctushas joined
alacerhas joined
kokonoehas left
kokonoehas joined
andrey.ghas joined
rtq3has left
Guushas left
Guushas joined
Guushas left
Kevhas left
rtq3has joined
wurstsalathas left
rtq3has left
larmahas left
delehas joined
delehas left
debaclehas left
larmahas joined
Guushas joined
Kevhas joined
alacerhas left
j.rhas joined
dwdhas joined
lorddavidiiihas joined
dwdlnj, Is qxmpp your project?
404.cityhas joined
olihas left
olihas joined
olihas left
olihas joined
rtq3has joined
lnjdwd: not its not, but I'm contributing to it
markhas left
markhas joined
Kevhas left
dwdlnj, Any idea if the example GUI does MIX at all? I saw the library does.
kokonoehas left
kokonoehas joined
lumihas joined
Zashhas left
ziniddwd, are you working at any XMPP projects nowadays?
Kevhas joined
dwdzinid, Trying to. :-)
dwdzinid, Both Threads Styling stuff (lots of gatewaying into other IM systems) and Metre. I should be doing Openfire too (although I'm not really sure they need my help right now).
dwdzinid, Current Threads thing is a standalone MIX implementation that I'm then building on to do our gatewaying interface. Hoping to get the MIX bits out as OSS for people to play with.
alacerhas joined
Zashhas joined
ziniddwd: okay
zinidgood to know someone is doing MIX
rtq3has left
alacerhas left
j.rhas left
alacerhas joined
Guusdwd we just upgraded MINA, and you're wondering if we need your help? 🙂
lnjdwd: I'm working on the MIX implementation in QXmpp, but it's not entirely finished and not all of my pull requests have been merged yet.
lnjBut all parsing / serialization of the main xep and xep 405 is working (in the unit tests).
markhas left
markhas joined
dwdGuus, That's what I mean, you clearly don't!
debaclehas joined
dwdlnj, Ah, OK. For my purposes, just a real client I can use for exploratory testing would be really helpful.
markhas left
alacerhas left
Guusdwd Imply what you want - we're still assigning all issues to you. 🙂
kokonoehas left
kokonoehas joined
Link Mauvehas joined
Guusdwd We'd like to welcome you home. Kindly re-auto-join open_chat 🙂
Yagizahas joined
ZashWould you kindly
GuusThat'd be as if I'm giving him a choice. Nope. 🙂
GuusWe need our glorious leader back!
GuusThe fashion industry has stolen him from us!
j.rhas joined
lumihas left
Alexhas joined
Alexhas left
nycohas left
Alexhas joined
Alexhas left
yonhas left
Alexhas joined
dwdSo - if a XEP-0060 node supports XEP-0313, the archived items are the events sent out? What about retracts when notify is set to false - do these events which don't get sent get archived nonetheless?
ralphmdwd: a retract is not an item, it is the removal of one, so I'm not sure if it is appropriate to store in MAM.
dwdralphm, What's in MAM then, if not events?
ralphmI.e. if you request items from a pubsub node, you only get items, and if a previously existing item was retracted, it will not be included in the result.
dwdralphm, Oh, certainly. But if you ask for the Things from MAM, that wouldn't be items, but events? Or what?
ralphmdwd: this is a good question. Either the MAM archive is a record of the notifications (even if they weren't sent?) or it is an archive of items.
ralphmI kinda expected the latter, to be consistent with the pubsub items iq results.
dwdralphm, I thought it was a good questioin when I asked it.
ralphmIt is
ralphmbecause we also have other notifications
ralphmlike node deletion
dwdralphm, Yes, this is true. Are those also events (as in {http://jabber.org/protocol/pubsub}event)?
dwdOh. Gosh. Lots of types I hadn't thought about.
MattJdwd, FWIW the pubsub stuff in MAM has never delighted me, for reasons like this. I've had a lot of feedback that it should at least be split out, but I haven't had time for that yet.
ralphmAnd items can include 'item' or 'retract'.
MattJI don't really understand what it would be expected to return, but I suspect it would have to leave a tombstone for retracted items
dwdMattJ, I would advocate splitting it out if it weren't for the minor point that there seems to be only one sentence of it...
MattJNo, there is more: https://xmpp.org/extensions/xep-0313.html#business-storeret-pubsub-archives
MattJOh right, that paragraph is a sentence
MattJNo, two
ralphmSince MIX critically depends on MAM and PubSub, this is something that requires a clear answer.
ThibGhas left
ThibGhas joined
dwdMattJ, SO that looks as if it's saying that it's the events that are stored, but the only mandatory event is the 'item' event (for publicaiton).
dwdMattJ, One assumes, therefore, that other events might be permissible. If one squints enough.
dwdralphm, This, incidentally, is why I'm asking the question.
ralphmSo really, events with <items><item/></items>
ralphmbut with retracted items excluded
dwdralphm, Yes. Sorry, it seems today everyone has to use very loose parsing on what I'm trying to say...
dwdralphm, No, it mentions no limitations, just a requirement to include the item publishes.
ralphmMAM in turn also seems to kinda support the notion of messages being removed from an archive, without providing protocol for it.
andyhas left
ralphm(section 3.2)
MattJIt definitely doesn't support the notion of messages being *removed*
dwdralphm, Seems reasonable. I suspect there are a number of use-cases for siilently removing a message from the archive.
ralphmMattJ: second paragraph
dwdMattJ, Blame Kev?
MattJThe second paragraph essentially explains that the entry is still there, but without a payload
ralphmBut, reading XEP-313's 5.1.3, I definitely read that as grafting the MAM protocol on top of a pubsub item store and faking it
ralphmI.e. not actually requiring storing events, but constructing them as if sent to a subscriber, wrapped by the envelope.
ralphmAlso note that it doesn't allow multiple items in one message, which /is/ ok for actual event notifications.
Marandahas joined
Alexhas left
ralphmFor what it is worth, I think this is fine.
ralphmThe only gap I see is that a client may not ever become aware of the retraction of an item.
ralphmbecause if it happened to be offline when the notification got sent, and the item is 'emptied' (as MattJ suggests), there will not be a thing representing that deletion in the archive.
ralphmHowever, on the other hand, the retract event *should* be in the user's own archive, assuming the model where the server manages the users subscription (PAM).
ralphmAnd given that, it is sufficiently consistent to me.
ralphmI.e. if you were not yet subscribed, retrieving the archive just lacks the retracted items, and is the consolidated state of things.
ralphm(retrieving it from the pubsub node)
ralphmdwd?
dwdprocesses.
ZashAnd where did the text about having to return item-not-found for unknown ids in RSM?
ZashAnd where did the text about having to return item-not-found for unknown ids in RSM come from?
dwdralphm, No, I think that sucks a bit. Asking a remote source for MAM items should yield the same result as asking your local source filtering for the remote sender. I think.
GuusWas there a DST switchover last weekend?
MattJUS changed, yes
Guus\o/ first time in ... ever ... that I learned about this _before_ being late for a meeting.
intosihas left
intosihas joined
404.cityhas left
j.rhas left
ralphmdwd: why? The first in this case is the archive of the pubsub node, and the second is the archive of messages sent to you.
ralphmGuus: make sure you tell Arc
Guusarc ^^
j.rhas joined
arcLol
arcIt's a DST miracle
dwd(In other news, I think I can make MIX without MIX-PAM work reasonably well, which might make it less of a forklift upgrade)
ZashAnd EU chickened out of abolishing DST :(
Tobiashas left
dwdZash, It may be the only positive from Brexit.
ralphmdwd: having MAM remember all the possible events sent to users for pubsub nodes is a bit terrible itself. E.g. it would need to record config changes.
ralphmNot even sure about subscription approvals
dwdralphm, Well sure. But for items, at least, recording old versions of items and retractions seems reasonable.
GuusZash wait what?
dwdralphm, Otherwise what's the point of having the archive?
ralphmdwd: why? The semantics of a publish request with the same item id, is that the previous item is obliterated and replaced with the new one.
dwdralphm, Besides which, it'd mean querying the MAM archive of the messages node of a MIX channel always gave you nothing. Boring.
ralphmIf you do an items request, you don't get that either.
ZashGuus: The EU considered abolishing DST changes, but chickened out and didn't give any requirements and "every country could do whatever they want", so it seems nothing changes and we get the stupid DST headache twice a year.
ralphmdwd: why would querying the mam archive of the messages node of a mix channel give you no items?
GuusZash fwiw, I thought that most countries would still go ahead and change it - although there might not be a uniform choice across Europe (and for those that do stop switching over, it's undecided if they'd go for summer, or winter time.
ralphmdwd: even though the notifications are sent as regular <message/> stanzas with bodies, there's no reason the message archive for the node to not return 'proper' constructed events as with every node.
dwdralphm, Because it's explicitly defined to not store pubsub items.
ralphmdwd: so that node is transient?
dwdralphm, See XEP-0369#4.7.2
ZashGuus: So without coordination we might get a worse mess than now.
GuusZash perhaps
dwdZash, Same time for any switches that do happen, mind.
ZashDon't most of the EU switch at the same time already?
markhas joined
ralphmdwd: wait, so in that section, which archive is being referred to? The archive of the messages node, or of the channel itself?
dwdralphm, It doesn't mention an archive there. But your proposal means that querying the archive for the MIX channel gives messages, whereas querying the archive of the messages node of the MIX channel doesn't.
dwdZash, They do, all, switch at the same time. The UK moved its changeover time, IIRC, by an hour, to match the rest of the EU.
ZashAnd is mostly in the same timezone (except the uk and finland?)
ZashAnd what's this about MIX and MAM?
dwdZash, And Portugal. Not sure about some of Eastern Europe either.
dwdZash, MIX, MAM, and '60.
dwdZash, But mostly, what's in a '60 MAM archive.
ZashDon't you get all messages regardless of whether you have online resources?
Zash.. to your account? So you could query them from there?
ZashAnd without getting a copy per joined resource?
Lancehas joined
ralphmdwd: well, I'm not sure if it a proposal, but it is one or the other. Either the messages node is persistent, but sends out notifications as regular messages instead of pubsub events, or it is not a real pubsub node, and subscribing to it just indicates the desire to get the non-event-but-bare-stanzas-with-payload messages.
arcZash no we get it four or more times a year because different parts of the world switch at different times
ZashI meant within the EU tho
ralphmIn the latter case, maybe having the archive be at the channel level, not the nodes it contains. I'm not sure how that interacts with hypothetical 'root node' subscriptions and their MAM archive.
markhas left
markhas joined
Marandahas left
Lancehas left
Alexhas joined
arcYea, that kind of thinking is problematic because it spreads. At a tech conferences here in the US, I keep hearing things like "xmpp? Don't they just use that in the EU?"
MattJNo, they also use it in the UK
ralphmZash: I think you want to scroll back to http://logs.xmpp.org/xsf/2019-03-11#2019-03-11-fb946fc83908ade3
ralphmarc: you could reply with 'Fortnite'.
dwdMattJ, Another 18 days until that works.
arcAdults don't understand fortnight
dwdarc, Eve Online. Origin. NATO.
dwdarc, Actually, your president doesn't understand NATO, at least. :-)
ralphmarc: adults are overrated
arcNot my president. He's only president for Nazis and rednecks
ralphmdwd: what about my message earlier?
dwdralphm, FWIW, I wanted the messages node to hold all messages. But I lost that one. My solution was to have MAM flags which could "condense" the items, for example by eliding retractions and corrected messages. I've been toying with the idea of such things to flag messages which have been acknowledged by '184, etc.
lovetoxhas joined
dwdralphm, But in any case, the MAM/MIX vs MAM/'60-on-messages-node is just a curiosity. Subscribing to the messages node with '60 syntax should/might give you a pubsub-syntax event stream of messages.
ralphmI am happy for something that condenses archived messages in general, although keeping in mind the discussion on multiple dimensions as discussed with Kev on the Summit.
mfosshas joined
dwdralphm, I don't remember the discussion being discussed.
dwdralphm, Did we discuss a discussion during the discussion?
ralphmHowever, I strongly believe that MAM on PubSub nodes currently are defined as a protocol to the item archive, not the message archive, and this is just a choice. I don't think right now that it is a bad one.
alacerhas joined
UsLhas left
ralphmTo cover the weird semantics of the messages node sending out notifications is a non-XEP-0060 syntax is something we could encode in the node configuration.
ralphmThere is (some) precedent for this.
ZashIf it was an archive of events then you'd probably want a way to filter them for the data payloads
mfosshas left
ralphmI remember that when Twitter supported XMPP pubsub (yes, really), it sent out atom elements and bodies in the bare message instead of using the event structure.
ralphmThe goal was to make it easier for client devs to work with.
Zashpubsub#include_body is pretty nice
ralphmyes and no
ralphmit would only cover the body
ZashTrue
ralphmBut we could define something similar
ralphmlike
ZashIncluding a picture would be neat in some cases actually.
Alexhas left
ralphma config item that represents 'bare notifications'
ZashWhat do you mean by "bare"?
ralphmZash: a notification without the pubsub event wrapper
ZashWait did they send `<message><{atom}item>atom stuff</item><body>someone tweeted hello</body></message>` without the pubsub container?
ralphmZash: we are considering what notifications a user gets when subscribed to the messages node in a mix channel, right?
ralphmSo at some point we said we wanted 'regular' messages to be sent as 'regular' messages originating in the channels' JID
ralphmHowever, you still have to subscribe to the 'messages' node.
ralphmFor all other nodes, you'd get notifications with the normal pubsub event wrapper.
ZashI'm afraid I haven't managed to read the MIX specs yet.
ralphmSo if we want to change that for this purpose, you'd have to have a flag to represent this behaviour.
ZashI remember discussions about that and thought containerless was the case already.
ralphmZash: yes, but implicit in the sense that if you just throw a pubsub service onto the jid representing a channel, it doesn't work that way.
ralphmZash: XEP-0369 now says something weird:
ralphm“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. ”
ralphmSo this is not very clear on the details.
zinidwhy isn't it clear?
zinidI find it pretty clear
zinidI implemented this part, didn't find caveates
ralphmzinid: if the pubsub item 'messages' doesn't hold items, what MAM archive does this text refer to?
ralphmpubsub node, I mean
zinidI don't know, but that's how MIX designed
zinidit's just weird
ralphmzinid: so instead of saying 'it is weird', we are trying to properly define it.
mimi89999has left
ralphmzinid
ralphmI didn't say the intent wasn't clear
kokonoehas left
zinidI mean the sentence "as an instruction" is clear. we have tons of weirdness in our XEPs, I kinda don't pay attention already
alacerhas left
zinidwhatever
mimi89999has joined
ralphmzinid: so to retrieve the MAM archive for the channel's messages, where does the client direct it? The channel JID? With or without a node?
zinidralphm, to channel jid, no need for any nodes
dwdzinid, +1
zinidthis node is kinda "ephemeral"
ralphmzinid: ok, I'll buy that, but that means that the 'messages' node is not really a pubsub node.
dwdralphm, We assume that directing XEP-0060 traffic to individual nodes gives you "classic" XEP-0060 stuff.
ralphmdwd: sure, I'm happy with that
ralphmbut the text I quoted should be more explicit on this
dwdralphm, And FWIW, the "subscription" to nodes is fully mediated by the MIX channel itself, so it can do "special" subscriptions for the messages node if done through a join. WHich is what I'm doing right now.
ralphmBecause even if it is a transient node, subscribing to it would normally yield empty notifications like this:
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='elsinore/doorbell'/>
</event>
</message>
ralphmdwd: maybe it would be better to say: there is no XEP-0060 style 'messages' node.
dwdralphm, Why empty?
ralphmdwd: right, good point. At least without an item id.
zinid> the "subscription" to nodes is fully mediated by the MIX channel itself
dwd, and that's the most weird thing of MIX. Back then when we implemented pubsub in ejabberd it was supposed to be a simple front-end to a database, now we introduce some "mediation" layer and the code is just useless now
dwdralphm, You're showing '60 Ex 3, there, which is explicitly a transient node that *also* doesn't have payloads.
zinidso the complexity now is how to design internal pubsub handlers to work above any "mediated" layer
zinidincluding database or MIX
dwdralphm, Whereas if you look at Table 4, bottom right is what we're expecting if you subscribe directly to the messages node.
ralphmRight, without item ids
dwdzinid, Right - in my toy implementation, subscriptions internally are callable types (functor objects), and so MIX just uses a different callable type for join'ed message subscriptions.
dwdralphm, No, they just don't *have* to have message ids.
dwdralphm, Argh. Item ids.
ziniddwd, sure, it's quite doable if you don't have a ton of code you need to redesign 🙂
dwdralphm, And probably wouldn't - there's a lot of complexity unspoken about whether the id on a message coming out from MIX is an item id in Pubsub terms or some new Event Id.
dwdzinid, Yes, as well I know from looking at doing similar in Openfire etc.
ralphmdwd: it'd be better to say: the messages node is special, no notifications, no archive, you just indicate you want normal message from the channel and *it* has an archive
yonhas joined
dwdralphm, I think it works anyway, doesn't it? We just need to say that asking for the MAM archive from the channel itself is a Different Thing.
dwdralphm, Noting, of course, that MIX implementations do nto have to offer very much (if any) classic XEP-0060 on the nodes within channels.
ralphmAnd that you don't get notifications from the node itself
ralphmWell, I definitely expect other nodes to be proper pubsub nodes
ralphmWith retract, purge, etc.
Alexhas joined
ralphmOr at least all the normal mandatory stuff
yonhas left
yvohas joined
kokonoehas joined
kokonoehas left
Nekithas left
kokonoehas joined
Guushas left
Guushas joined
ThibGhas left
ThibGhas joined
Lancehas joined
yonhas joined
Guushas left
Guushas joined
Marandahas joined
intosihas left
lumihas joined
UsLhas joined
Tobiashas joined
kokonoehas left
kokonoehas joined
zinidhey guys, any input on my last ranting on standards@ list?
Ge0rGzinid: how do you protect from sybil attacks, again?
zinidGe0rG, by concentrating identities checks in a few single place, at CAs
zinidnote that for now we don't need the checks to be extremely severe, something like oauth to popular services or sms verification is enough so far
Ge0rGwhy is a sybil attack even a problem at all?
zinidGe0rG, in p2p?
zinidbecause you can polute routing
Ge0rGin the CA thing.
zinidaka Eclipse attack
dwdhas left
dwdhas joined
zinidsybil attack is not a problem is CA, CAs are just centralized to prevent Sybil
zinid*in
moparisthebestidk, the CA looks like a total dealbreaker to me
zinidmoparisthebest, why?
moparisthebestmaybe that makes it vulnerable to a sybil attack but probably worth it
zinidI recall you like DNS, but DNS is ICANN - same centralized stuff
moparisthebestI don't know anyone or any organization I trust enough to run a CA
Ge0rGzinid: but how is a CA supposed to prevent sybil attacks?
dwdhas left
moparisthebestI only trust certificates as far as the public key anyway, hence why I like DNSSEC + DANE etc
zinidGe0rG, I wrote already:
> note that for now we don't need the checks to be extremely severe, something like oauth to popular services or sms verification is enough so far
zinidmoparisthebest, but what's the difference?
Ge0rGzinid: but that would mean that you essentially don't verify the identity of the XMPP entity but instead of whatever third-party service you use?
Ge0rG(actually, "in addition to")
zinidGe0rG, you can verify the entity of course by asking to provide the passport 😀
zinidwithout CAs you don't have even that: you cannot identify all your online contacts that way
moparisthebestto clarify, I like the idea of identifying an XMPP *account* (not device, could be multiple devices) with a cryptographic key
j.rhas left
moparisthebestI don't like the idea of a centralized CA approving that
Ge0rGzinid: I still think that you are conflating multiple different problem domains. There is value in having an XMPP based CA hierarchy, and there is value in whatever sybil attack prevention mechanism you might require for RELOAD. But those are completely separate
j.rhas joined
zinidGe0rG, sure they are separate
zinidbut I don't solve separate problems
zinidI separate a single meta problem
moparisthebestzinid, if you are looking for "trust" then each domain should have it's own level of trust, which gets passed to it's users, imho
zinidI'm not interested in our permanent bikeshedding with small problems without seeing a complete picture
moparisthebestthat keeps it federated
zinidmoparisthebest, it's possible to do and I outlined that in XEP-0416
zinidbut still Sybil resistance is a problem and you CANNOT address it without centralization, and clever people proved that
moparisthebestthen it shouldn't be addressed...
zinidalso, what's the point in federated accounts? why not roaming user profiles? we're moving that way in Moved for example
moparisthebestas you pointed out it's already basically centralized and could be solved that way through DNS
zinidso we just rely on CA instead of DNS, both are centralized
moparisthebestif entire domains are trusted/not and excluded/not attackers already can't buy an unlimited number of those
zinidmoparisthebest, I can create 100500 accounts on another poorly maintained server and attack your server, what will you do?
moparisthebestblock that 1 server
Steve Killehas left
zinidoh great idea 🙂
zinidto block other users on that server?
moparisthebestno problem, they can use their crypto identity to move to another one :D
dwdhas joined
zinidmoparisthebest, how that?
zinidwhere will they get the identity? how will they move?
zinidfrom *abandoned* server
zinidnot to mention they will of course not move anywhere
moparisthebestthey generate the identity, all their contacts have that key, when they get a request from $new_account with that same identity, they know they've moved
zinidand you will trust the identity signed by that rougue server?
Lancehas left
moparisthebestit's not signed by anyone
zinidmoparisthebest, also, can you please outline your concerns with CAs?
frainzhas left
zinidlet's encrypt is bad?
frainzhas joined
moparisthebest1. assuming good intent and all that, commercial CAs get hacked/compromised all the time, what "XMPP CA" would even be as good?
moparisthebest2. I don't like assuming good intent, or being at the whim of anyone else
zinidmoparisthebest, and DNS servers are not hacked all the time?
zinidand DNS assumes not intent?
moparisthebestno? also there isn't a single source of truth DNS server
olihas left
zinidexcept root servers?
zinidwhatever, what you say is possible if every XMPP server maintains CA
zinidtied to their domains
zinidbut it sucks
zinidalso, good luck create roaming profiles in such system: why would I trust identities signed by some server X?
zinidit's even moot that CA and much easier to compromise
zinid*than
moparisthebestI don't think there should be CAs at all, only account keys, generated on an end device on account creation, sync'd to other devices
zinidmoparisthebest, and how will you verify those keys?
moparisthebestmanually, or PGP web-of-trust style ? :P
XSF Discussion - 2019-03-11