jonaswpep., even though, all I can do is re-try really, because xmppoke doesn’t give useful logs in any way
danielhas left
jmpmanhas joined
Guusjonasw: many failed tests on the webpage now.
jonaswGuus, you could check if everything is in order inside the poker by invoking xmppoke manually:
cd /opt/xmppoke; luajit /opt/xmppoke/xmppoke.lua --db-host=... --db-password=... -d=10 $domain
jonasw(the "=" between option and value are important)
jonaswI also wonder whether we get an interesting type of spam there
ralphmhas joined
ralphmhas left
jubalhhas left
moparisthebesthas joined
tim@boese-ban.dehas joined
zinidhas left
Guusjonasw, sorry, can't check now. Travellig.
jonaswno worries
jonaswnow we’re getting quite a few sensible ones again
jonaswit’s also possible most of what we saw was simply in progress
Guusperhaps
Guushas left
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
ralphmhas joined
edhelashas left
ralphmhas joined
jabberatdemohas joined
danielhas left
danielhas left
jabberatdemohas left
jcbrandhas joined
danielhas left
danielhas left
Steve Killehas left
edhelashas left
Steve Killehas left
ralphmhas left
danielhas left
mimi89999has left
danielhas left
edhelashas joined
efrithas left
ralphmhas left
goffihas joined
efrithas joined
lskdjfhas joined
archas left
archas joined
danielhas left
@Alacerhas joined
@Alacerhas left
Martinhas joined
@Alacerhas joined
Steve Killehas joined
Martinhas left
blablahas joined
blablahas joined
blablahas joined
zinidhas left
uchas joined
stefandxmhas left
ralphmhas left
danielhas left
@Alacerhas left
@Alacerhas joined
Zashhas joined
zinidhas left
vanitasvitaehas left
lumihas joined
vanitasvitaehas joined
Holgerhas left
jerehas joined
zinidhas left
stefandxmhas joined
Zashhas left
archas left
archas joined
archas left
efrithas left
archas joined
stefandxmhas left
danielhas left
danielhas joined
Zashhas joined
@Alacerhas left
@Alacerhas joined
ralphmhas left
jerehas joined
zinidhas left
ralphmhas left
jerehas joined
Steve Killehas left
jerehas joined
stefandxmhas joined
zinidhas left
waqashas joined
valohas joined
valohas joined
@Alacerhas left
waqashas left
waqashas joined
la|r|mahas joined
danielhas left
@Alacerhas joined
danielhas left
ralphmhas left
uchas joined
jerehas joined
Syndacehas left
Syndacehas joined
jjrhhas left
jerehas joined
jjrhhas left
jerehas joined
jjrhhas left
jjrhhas left
Ge0rGmarc: https://mail.jabber.org/pipermail/standards/2016-June/031152.html (more on-topic in here)
Ge0rGmarc: also another thing I wanted to tell you yesterday: the current PARS token generation doesn't need server interaction, so it's immediate on the client, even if you are on the worst imaginable mobile connection
marcGe0rG, just the two posts?
Ge0rGmarc: there's a loooong thread going into 2017.
Ge0rGmarc: https://mail.jabber.org/pipermail/standards/2017-April/032599.html and https://mail.jabber.org/pipermail/standards/2017-May/032616.html
Ge0rGwith their respective "next in thread"
marcGe0rG, okay, maybe I find some time to read it
@Alacerhas left
waqashas left
@Alacerhas joined
Ge0rGmarc: you owe me half an hour of time anyway, for yesterday's discussion :P
waqashas joined
zinidhas left
marcGe0rG, :P
marcGe0rG, are you on 34c3?
Ge0rGmarc: I don't think so
marcToo bad
jonaswmarc, the traditional XSF meetup is at FOSDEM
jonaswthe SUMMIT
marcjonasw, okay, maybe I'll come to FOSDEM as well :D
jonaswI need to schedule that for me
jerehas joined
dropcash77has joined
dropcash77has left
pep.has left
danielhas left
uchas left
jerehas joined
uchas left
uchas left
marcGe0rG, are you on FOSDEM 2018?
Ge0rGmarc: I might be able to make it to the SUMMIT. Maybe.
Ge0rGmarc: at least I've prepared a talk about what's wrong with XMPP ;)
marc:D
marcGe0rG, but not submitted, right?
Ge0rGmarc: you can't submit to SUMMIT
Ge0rGmarc: the XSF summit is a separate conference taking place in the days before FOSDEM
marcGe0rG, ah
Guushas left
Guushas joined
marcI was talking about FOSDEM submission :)
Ge0rGmarc: https://wiki.xmpp.org/web/Summit_22
jerehas joined
Ge0rGmarc: giving my talk at fosdem would be a huge disservice to the XMPP community
marc:D
Ge0rGor I would end up with a reputation similar to Poettering :P
lovetoxhas joined
jonaswhe's fun when he crashes other peoples talks
Ge0rGI've crashed a talk about SCCS once. It was not particularly challenging
Flow Ge0rG who gave the talk?
Ge0rGFlow: I'm not naming names here, but it was at a conference venue known to you.
jcbrandhas left
Flowschilling at CLT
Guushas left
efrithas joined
sonnyhas left
sonnyhas joined
Tobiashas joined
danielhas left
sonnyhas left
sonnyhas joined
danielhas left
jcbrandhas joined
jubalhhas joined
Kevhas left
sonnyhas left
sonnyhas joined
mimi89999has joined
jerehas joined
sonnyhas joined
sonnyhas joined
efrithas left
danielhas left
danielhas left
lskdjfhas left
marcGe0rG, almost everybody except you is voting for server-side implementation, is that correct? :D
Ge0rGmarc: I'm not opposed to server side implementations, but please have a look at bookmarks in PEP.
marcthe pep idea has some nice features
marcGe0rG, bookmarks in PEP? what do you mean?
Ge0rGmarc: the bookmarks xep recommends pep as the storage backend for a decade now, and there is no proper server support yet
marcwell, the PEP can not be used for user-invitation because it can not be limited
marcthis is not good for account creation :D
KevGe0rG: No, that's just not true. You mean that Prosody doesn't support it, which isn't the same as there being *no* support.
edhelasKev +1
marcbut I like the idea of generating offline tokens
Ge0rGKev: last time I've heard that prosody completely lacks support, whereas other widely deployed implementations only leak your bookmarks to the general public.
Ge0rGKev: from a client interoperability perspective, that discussion is moot anyway.
edhelasthat's false
HolgerGe0rG: Er, this is specific to bookmarks, and the reason is that the XEP is broken.
goffihas left
edhelaswhitelist support is quite great
HolgerGe0rG: Daniel is currently trying to fix it. Once that happened, it will be fixed in the next ejabberd release, for example.
edhelasHolger Daniel is trying to fix what ?
HolgerWell, I should say "probably" I guess :-) But I'm quite confident.
Holger(I was assuming that this is Ge0rG's point.)
edhelas"specified perist_items"
edhelassmall typo in the PR :p
danielGe0rG, ejabberd leaks your private pep nodes to the public?
Ge0rGKev: I don't have stats, but I would say that ejabberd and prosody are the most widely deployed servers. They lack support for a feature that's specified for a decade now.
Ge0rGKev: now please try to convince me this won't happen to server-side-PARS.
danieli think one could implement bookmarks in pep on conversations.im
Ge0rGdaniel: isn't that why you are trying to fix 60 now?
danielGe0rG, no?
Ge0rGdaniel: I'm sure this will be approved by the Conversations Council of Elders.
HolgerGe0rG: Unless you configure the node with access_model=opoen, then of course it's not leaked.
Ge0rGHolger: I'm sorry for being ignorant about 0060, but what's the default access_model?
HolgerGe0rG: 0163 says "The default access model is 'presence'."
ZashFor PEP
Ge0rGHolger: so bookmarks are only leaked to your contacts?
jubalhhas left
goffihas joined
edhelascan we not change that to whitelist ?
Zashedhelas: For PEP? That'd make it useless
edhelasservers can also enforce access_model for some PEP namespaces
edhelasthe issue is that the user will have to know if the access_model is good somehow
ZashI was intending to have some defaults for well known PEP nodes coded in.
HolgerGe0rG: I know that 0048 uses publish options to set the access model. Right now this doesn't work because it conflicts with 0060. The thing I don't understand is why you take this as an example for servers being slow with implementation. You can't implement a broken spec.
Zashedhelas: That's what you use publish-options preconditions for
edhelasokay
edhelasnever heard of it
KevAnd therein lies the problem.
ZashBut, it's like the most starred issue in the Prosody issue tracker ^^
HolgerGe0rG: But clients can configure the node's access_model even without that spec fix, of course.
ZashMostly because it has its own marketing team, but still
Kevpublish-options isn't exactly well-specified, which is what Daniel's just brought up on list.
daniel> was intending to have some defaults for well known PEP nodes coded in.
Zash i'm planning on writing a module that just disables access control for omemo pep nodes. that's why i asked about how to write modules the other day
edhelasah, here's another piece of 0060 that I'm discovering today
Ge0rGHolger: bookmarks is referencing 223 for over a decade now. Please don't tell me nobody noticed it's broken until now.
ZashGe0rG: I'm sorry, but nobody noticed that it is broken until now.
HolgerGe0rG: I think I mentioned it on standards@ quite a while ago.
Ge0rGSo apparently nobody implementing servers cared enough about this spec, for over a decade.
danieli noticed about a year ago. i just didn't get around to write a PR
HolgerYeah sure.
ZashGe0rG: Correct
KevGe0rG: They didn't, because 49 for 48 worked fine and there was no reason to change.
HolgerIf a spec is broken, blame server devs.
KevAnd 223 was meant to be a profile of 60, so no-one read 223.
Ge0rGAnd 0060 is so mind-boggingly complex that nobody read that either.
ZashSoooo, we should get around to finishing that 60 splitup
Ge0rGSo everybody just bails out on "*pubsub*"
jonaswGe0rG, that’s not true, I read it!
Ge0rGAnd now people come and try to convince me to make my shiny new account registration flow depend on all that mess. Thanks, but no thanks.
Holgerjonasw: Me too, but that doesn't help, because the text changes whenever you re-read it.
danielwe should really revisit that hiring famous actors and actresses to make audiobook versions of XEPs
Ge0rGdaniel: you can't imagine how much time you need to spend to explain to them the corrent pronounciation of all the tech terms
jonaswHolger, that was my impression too
edhelasdaniel :D Book 36 - Pubsub - Chapter 342 - Configuring your node, 64min
Holger:-)
Ge0rGedhelas: that title almost reads like a Bible verse.
Ge0rG"And so saith Saint Peter: it shall be XML"
edhelas0060 is a bit like the Bible, each people reading it have their own understanding
mathieuiand let’s not talk about the religious wars
mathieuiand their thousands of casualties
ZashDon't mention the war
Ge0rGOkay, let's longjump out of this mess again. My initial provocative statement was "nobody is implementing server-side PEP bookmark storage". Let me change that to "PEP bookmark storage is mandated for a decade now, and nobody noticed that it's essentially broken for so long"
moparisthebestHAHAHA I almost spit out coffee [10:17:02 AM] edhelas: 0060 is a bit like the Bible, each people reading it have their own understanding
moparisthebestthat needs to go in the implementation notes of 60 or something
jonaswGe0rG, where did we setjmp though?
Ge0rGjonasw: just unwind enough stack to get back to PARS
mathieuiGe0rG, I did notice
danielGe0rG, in any case, as a council member you could read my two! PRs on xep60 and form an opinion on which one you prefer
Ge0rGdaniel: I suppose this is unavoidable.
Ge0rGdaniel: and still, I lack sufficient understanding of 0060 so far to be able to contribute an informed opinion. I'll work on it.
danielhas left
la|r|mahas left
zinidhas left
jubalhhas joined
efrithas joined
Ge0rGCould we please mandate that a server with IBR also MUST provide valid XEP-0157 contact info?
archas left
archas joined
ZashWrite a XEP
ZashInfo XEP on "Things your public server should support"
Ge0rGyou can't enforce info-xep's
uchas left
jonaswGe0rG, you can if you check it on s2sin :>
jonaswand send a <policy-violation/> stream error back.
Zash-xep 222
Ge0rGjonasw: technically, I can. But if it's not official policy, I am not allowed to
Zash-xep 223
BunnehZash: Persistent Storage of Public Data via PubSub (Informational, Active, 2008-09-08)
See: https://xmpp.org/extensions/xep-0222.html
BunnehZash: Persistent Storage of Private Data via PubSub (Informational, Active, 2008-09-08)
See: https://xmpp.org/extensions/xep-0223.html
jonaswGe0rG, that’s why the info XEP :)
ZashInformational, both. Why nobody looked at them?
sonnyhas left
sonnyhas joined
la|r|mahas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
zinidhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
jerehas joined
lskdjfhas left
danielhas left
jerehas joined
jerehas joined
lskdjfhas joined
lskdjfhas left
lskdjfhas joined
lskdjfhas joined
lskdjfhas left
lovetoxhas left
zinidhas left
HolgerIf a server stores groupchat messages into the user archive, the server would have to de-duplicate if multiple resources joined the room, right?
ZashYes
HolgerFun.
Ge0rGIt will also be fun for the client to receive those messages without realizing it was a MUC
Ge0rGnot so bad for proper MUC messages, but MUC-PMs will be a PITA
Ge0rGAre MUC-PMs to be stored in the user's MAM?
danielHolger, Zash: also outgoing and reflected
ZashMakes purely append-only storage reeeeally hard
Ge0rGFinally, the server devs are going to experience the joy of synchronizing a MUC history.
danielFun fun fun. All for having an incomplete archive of the room
Ge0rGEspecially the ones calling for MUC messages in MAM.
ZashI don't wanna!
Ge0rGZash: I don't see you complaining on standards@
HolgerMaybe the user archive should query the MUC archive to sync missing messages.
Ge0rGHolger: awesome idea.
Ge0rGAnd the MUC archive should just crowdsource the request to other participants' MAMs.
Ge0rGDistributed storage!
Ge0rGIt's all in the cloud now!
Ge0rGwanders off, laughing weirdly.
moparisthebestsince the cloud is just other people's computers everything has always been there
jerehas joined
lskdjfhas left
lskdjfhas left
ZashMaybe the clients could send MAM queries to each other!
Ge0rGZash: then we don't need MUC any more. Just have clients poll each other in a round-robin way to distribute history and messages
ZashGe0rG: Next, have them connect to each other instead of servers!
danielhas left
jonaswZash, somebody seriously suggested that a while ago
jubalhhas joined
Zashjonasw: Was it me?
danielhas joined
jonaswI don’t think so
jonasw(and I’m referring to "Maybe the clients could send MAM queries to each other")
ZashYou could in theory do that among your own clients and have serverless MAM
Ge0rGZash: ChatSecure used to bundle a HTTP server, minidns and some other tech debt to allow for serverless messaging
ZashWTF HTTP server?
Ge0rGI don't remember any more the rationale for that.. picture sharing maybe? Or forwarding of the app APK?
Ge0rGBut I remember their stack was so high it resembled the tower of babel.
marchas left
danielHttp over otr
danielFor file transfer
jerehas joined
Ge0rGright!
ZashWhy not p2p http. Like p2p proxy65 that already exists
Ge0rGSo should I implement XEP-0049 in yaxim now?
jonaswGe0rG, yes
KevI think client-only MAM is not at all stupid - and is probably the only sane thing to do in the world of E2E.
ZashIt wouldn't be too hard to sync bookmarks between PEP and private xml
jonaswZash, would be great to have that in prosody
Ge0rGKev: client-side MAM queries that get around E2EE are also stupid.
Ge0rGOr at least notoriously hard to get right.
Zashjonasw: Depends on PEP with configurable access models, which isn't quite there yet.
ZashIn theory possible to hard-code some nodes to be private
KevGe0rG: Sure. Just needs a vector clock and the server to inject MAM IDs into every stanza, right? :)
jonaswZash, might not be the worst idea
blablahas joined
Ge0rGKev: I'm not quite sure what you are referencing, and I'm even less sure I can keep my sanity if you explain it.
KevNot worth thinking about. I'm just distracting myself from far too many hours worth of Council work.
KevI'd forgotten how much of the week Council takes.
ZashKev: Vector clocks? I thought blockchain was the hip thing for everyhing now?
KevChoose your poison :)
danielhas left
danielhas joined
jonaswmy favourite gem out of XEP-0153 (vcard avatars):
> The XML character data of the <TYPE/> element is a hint. If the XML character data of the <TYPE/> specifies a content type that does not match the data provided in the <BINVAL/> element, the processing application MUST adhere to the content type of the actual image data and MUST ignore the <TYPE/>. If the <TYPE/> is something other than image/gif, image/jpeg, or image/png, it SHOULD be ignored.
jonaswTL;DR: ignore <TYPE/>
danielKev: I'm not sure if "all messages I ever received excluding messages I didn't receive in group chats because I was offline" is actually a use case you have or if you just believe it to be the right thing. We have mam for a couple of years now and none of the servers seem to store them and I haven't seen anyone complaining that their mam archive *lacks* group chat messages
KevM-Link does, FWIW, although not in all circumstances.
jonaswI’m pretty confident that having MUC groupchat in MAM is horrible
Ge0rGI think that adding any MUC messages into local MAM opens up a can of worms.
KevI could be wrong on this one, but over the weekend I convinced myself I was wrong before when I thought I was wrong, and that I was originally right.
debaclehas joined
KevSo I'm not refusing to make the proposed change, but I'm not sold on it at the moment.
Ge0rGKev: could you please annotate your right-wrong statement with the content of the respective opinions, so others can follow?
danielIt will always be incomplete be definition. It will be a nightmare to dedup with muc history coming in multiple time and receiving the reflections for outgoing messages
KevI originally though MUC should be in MAM. Daniel said it shouldn't, and I temporarily believed him, but when I went to make the change I persuaded myself MUC belongs in MAM again.
danielSure the dedup issues can be resolved
danielBut to what end? Almost all clients will throw the messages away or not request them
KevDedup sounds like a somewhat strong argument.
Holger"Incomplete archive" sounds stronger to me :-)
KevI don't think it's an incomplete archive, is it?
KevIt's a complete archive of what the user has received in her live sessions.
KevIt's incomplete w.r.t. to the MUC, but that's ok because the user wasn't in the MUC at the time.
HolgerSure. We invented MUC MAM because users didn't perceive this as "ok".
HolgerI thought.
Ge0rGusers want a full MUC archive.
KevThat's probably true, and one reason for MIXxing it up.
Ge0rGI've heard that messages getting lost is the #1 problem with XMPP.
KevCould someone collate all these reasons and shove them in response to my mail to standards@ so we have a record in the right venue, please?
Holger(I did respond with mine already.)
zinidhas left
Ge0rGToday I got a dozen of error bounces for half an hour worth of conversation I had with a friend, because his mobile client's session was hibernated and killed, and apparently the mobile client was receiving full messages and not just carbons.
bjchas joined
KevCarbons are a *nightmare* for bounce handling.
KevIf you want to talk about server dedup handling being nearly impossible - Carbons can be taken out and shot immediately :)
lovetoxhas joined
bjchas left
Holger"When a server attempts to deliver a (locally generated) carbon copy, and that carbon copy bounces with an error for any reason, the server MUST NOT forward that error back to the original sender."
Ge0rGKev: I received error bounces from my contact, and error bounces for Carbons should go to the account and not to the chat partner, so obviously there were no carbons involved.
KevHolger: But what when the carbons were delivered and the originals bounced? It's horrid.
KevGe0rG: ^
Ge0rGKev: yes. That's exactly what happened.
HolgerKev: Yes. Or when the user will receive the messages from MAM.
HolgerYou can easily make the right decision simply by looking into the future.
Ge0rGI had a nice conversation full of green checkmarks, and then *BAM!* the zombie exploded and it was all full of "✖ cancel: recipient-unavailable"
KevHolger: I'm not convinced it'd be easy, even then :)
danielThe real jid annotation for non anonymous mucs also won't work if the archive is on the user's server
danielI've made all these arguments in my original mail by the way
KevAll of them? I'd forgotten about dedup, in that case.
Ge0rGIt wasn't explicitly called dedup, but:
> And even worse the messages will be included in a normal catchup (when I don't necessarily want them)
Ge0rGSo, what about storing MUC-PMs in MAM?
KevThose you certainly want in there, because they won't be stored anywhere else. That much I'm confident I'm not wrong about.
jonaswGe0rG, blame the client for taking type='error' responses into account after a MDR has been received.
Kev(The real-jid thing is a problem with stripping elements, that I'm fairly convinced MAM shouldn't do too liberally)
jonaswKev, MUC-PMs are really bad in MAM. how would a client not knowing about the MUC distinguish one or more MUC-PM conversations in the same MUC from a single conversation with a random entity?
Ge0rGjonasw: in a multi-client scenario, there is no right way to handle MDR / error responses, in any order.
jonaswKev, MUC-PMs are really bad in MAM. how would a client not knowing about the MUC distinguish one or more MUC-PM conversations in the same MUC from a single conversation with an entity having the MUCs JID?
Ge0rGjonasw: <x/> tags!
jonaswGe0rG, what’s wrong with MDR wins?
Holgerjonasw: MUC PMs are really bad regardless of MAM.
jonaswHolger, no reason to make them worse by offering them to clients which don’t even know about the MUC
Kevjonasw: The issue there is really clients not knowing that it's a MUC - and they do have that information available to them.
jonaswKev, so essentially clients need to support XEP-0045 to use MAM? :)
Ge0rGjonasw: "MDR wins" will lead to situations where only a buried secondary client received the message and MDRed it, and it still didn't arrive where it was urgently needed
Holgerjonasw: So don't offering them to clients who do know about the MUC is the obvious solution?
Holgers/don't/not/
jonaswHolger, I think so
Ge0rGKev: clients don't generally know which JID is a MUC
Holgerjonasw: "Jonas, you installed me this app and now I LOST MESSAGES!"
Steve Killehas left
KevGe0rG: They can do, they only have to ask.
jonaswGe0rG, tricky, but then again, that other client which wanted to have them is offline, and should sync with MAM on reboot
danielI mean the dedup issue can be solved fairly easily by a simple store everything and blame the clients rule
Steve Killehas left
jonaswHolger, we should disable MUC PMs in all clients.
jonaswbeing polemic here :)
danielPlus nobody will notice because we will just discard messages anyway
Holgerjonasw: I would agree if you weren't polemic :-)
daniel> jonasw: I would agree if you weren't polemic :-)
👍
jonaswHolger, I may be even serious, I’m not entirely sure.
Ge0rGKev: that involves at least one connection over an unreliable network medium.
Ge0rGjonasw: except not all clients support MAM.
Ge0rGKev: in your client architecture, it might be okay to delay the processing of an incoming message until a separate query to a server has been fired off and completed.
Ge0rGI just hope that you have a query manager that doesn't fire off the lookup for each individual message in the MAM flood.
Steve Killehas joined
jerehas joined
Ge0rG> Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration.
What does that sentence from 0060 mean in English?
ZashYou have to say what the field does when you register it.
Ge0rGwhen I register the field?
jcbrandhas left
jerehas joined
jerehas joined
ZashYes. In the registry for that. Publish-options?
Ge0rGBut I'm publishing an item, not registering a field.
ZashGe0rG: Do you want to know what each of those three terms mean or somethnig?
jonaswGe0rG, I hate things
Ge0rGZash: that, too.
Ge0rGZash: it just doesn't make any sense to me.
jonaswGe0rG, <publish-options/> uses a form with defined fields
Ge0rGjonasw: right.
jonaswthe field registry tells you whether it’s METADATA, per-item OVERRIDE or PRECONDITION
jonaswthe sentence you quoted enforces that
Zashpreconditions makes the publish fail if the value does not match the node config
Zashoverrides changes the node config, but only for that item
Ge0rGjonasw: when grepping the XEP for METADATA, I only find other metadata and the quoted sentence, not an explanation.
ZashGe0rG: "metadata"
ZashGe0rG: I think that might be what the stuff in Push is
Ge0rG§5.4 Discover Node Metadata?
danielGe0rG, it exists because you have to register all form fields and you might want form fields that are NOP
Ge0rGor maybe Stanza Headers and Internet Metadata (XEP-0131)?
danielhttps://gist.github.com/iNPUTmice/7c52785ed69787516abb60e31703dbd2 describes how to use publish-options from a client perspective in case this helps
Ge0rGdaniel: thanks, maybe that will enlighten me.
jonaswGe0rG, https://xmpp.org/extensions/xep-0357.html#publishing Example 13. Server publishes a push notification with provided publish options
jonaswI think that’s an example of metadata
jonaswit is neither a precondition nor a per-item override
jonaswit is neither a precondition nor a per-item override of configuration
jonaswbut something which is used by the pubsub service to do things
ZashDo Things™
Ge0rGokay, so publish-options is overloaded with three comepletely different semantics, one of them to add meta-data content to the published event, another to check node configuration and a third one to change node configuration for this item?
ZashYes
jonaswGe0rG, yes.
Ge0rGCan't they just write that into the XEP?
ZashIt would be nice to split that into three different forms.
goffihas left
ZashBuuuuut uh
danielfwiw one of my PRs gets rid of override
Ge0rGZash: I presume "But backward compat"
ZashGe0rG: p much
Ge0rGnow I need to understand what "node configuration" is.
danielbecause it was never used we can savely removeit
HolgerOr just ditch METADATA and OVERRIDE.
ZashAltho since nobody used any of that until daniel started doing it with OMEMO ...
ZashHolger: And ditch PubSub in Push entirely?
HolgerZash: Yes, currently it's non-standard anyway.
daniel> Altho since nobody used any of that until daniel started doing it with
that's probably true for a couple of things
ZashAltho it is mentioned by 222 or 223, which nobody supports.
ZashSo, nm
HolgerZash: push says I can add arbitrary custom data. 0060 forbids that.
ZashHnng
danielZash, the push xep is not really an issue because that particular pubsub service doesn't have to annouce publish-options and all is good
danielput we can register that one push publish-options keyword as metadata if you prefer that
HolgerYes, it is just not a PubSub service.
danielit's just the app server sort of accepting one pubsub like command for what ever reason
HolgerAs you can't use a standard PubSub service for this anyway, it doesn't matter indeed.
zinidhas left
Holgerdaniel: ChatSecure uses different fields FWIW.
danielEither way it doesn't conflict wit the wording in xep60
tuxhas joined
jjrhhas left
HolgerWell but only because this is not 0060-PubSub but a 0357-specific protocol with PubSub-like syntax.
danielhas left
HolgerThis still annoys me but admittedly it's a separate issue.
jjrhhas left
Ge0rG0357 is overly complex, isn't it?
jubalhhas joined
danielYou just couldn't run a pubsub service and an app server on the the jid
danielNot sure why one would want that
HolgerGe0rG: No it's simple IMO. Just (a) underspecified and (b) used PubSub-like syntax for no good reason except to mislead client developers into believing they could use a PubSub service when implementing an app server.
Holgerdaniel: Yes there's just problem if the developer understands all that.
Holger*no problem
stefandxmhas left
jjrhhas left
jjrhhas left
zinidhas left
uchas left
uchas joined
jcbrandhas joined
jonaswokay
jonaswnow for real: what is the most deployed avatar protocol currently?
ZashDefine deployed
jonaswactually used in the wild
jonasw"will make my client show an avatar with the highest likelihood"
tuxhas left
jcbrandhas left
Zash"All of the above"
ZashMake a thing that collects stats?
jonaswI’m slightly frustrated after seeing that XEP-0153 support doesn’t bring much in my roster and now I’m afraid that it might in fact all be xep8
ZashConversations popularity might have shifted it quite a bit for 84
BunnehZash: User Avatar (Standards Track, Draft, 2016-07-09)
See: https://xmpp.org/extensions/xep-0084.html
jonaswZash, that’s good
jonaswI don’t feel so alone anymore
ZashLet's all just switch to xep 8 and {xep user profile}
BunnehZash: Multiple matches:
User Profile https://xmpp.org/extensions/xep-0154.html
Extensible SASL Profile https://xmpp.org/extensions/inbox/sasl2.html
Tree Transfer Stream Initiation Profile https://xmpp.org/extensions/xep-0105.html
Profiles https://xmpp.org/extensions/xep-0006.html
XMPP Date and Time Profiles https://xmpp.org/extensions/xep-0082.html
Message Stanza Profiles https://xmpp.org/extensions/xep-0226.html
Extensible SASL Profile https://xmpp.org/extensions/xep-0388.html
User Mood https://xmpp.org/extensions/xep-0107.html
User Tune https://xmpp.org/extensions/xep-0118.html
User Time Zone https://xmpp.org/extensions/inbox/peptzo.html
User Avatar https://xmpp.org/extensions/xep-0084.html
User Activity https://xmpp.org/extensions/xep-0108.html
Zashoh dear
jonaswI‘d like to know for example how the heck to get georgs avatar
ZashAfter performing an unscientific test, 27% of presence I see seems to have vcard-temp
jonaswany jabber:x:avatar?
ZashIn a moment
jonaswthank you very much for measuring
ZashThis CLI client tends to become unhappy about presence floods
Zashrlwrap + long, colored lines => unhappyness
ZashAlso, FWIW, I did not count the cached presence I got, which has only <show> and <delay>
jonaswI’m happy with a > 0 result in fact
ZashHm, but are these even comparable?
jonaswwhy wouldn’t they?
Guushas joined
ZashNot all servers send presence for offline contacts
ZashAlso some may have multiple online devices
ZashI get '84 notifications from 37% of contacts
ZashAnd like 2.4 presences per contact...
jjrhhas left
Zashjonasw: 153 needs at least one *currently online client* to work (or you could poll vcards)
jonaswZash, does it?
ZashWhile 84 needs at least one client to have published an avatar at some point in the past (modulo server persistence support or uptime)
jonaswbut 153 stores the avatar at the server, too?
jonaswand there’s that presence notification thing
Zashjonasw: Right. Notifications as defined by 153 requires an online client. Altho I suppose a server could inject the thing into offline presence.
ZashNot aware of any doing the later
ZashCould inject into online presence too
ZashServer could even sync the avatar data between them. Mine does that for example.
jonaswcan we have that in prosody? ;-)
ZashWrite a plugin ;)
jonaswhow does your server do that?
zinidjonasw, done in ejabberd like 10 years ago 🙂
Zashzinid: which part?
zinidZash, both
zinidpep<->vcard sync, and xupdate injection
goffihas joined
jonaswzinid, neat, that probably explains why I’m seeing a lot of PEP avatars
zinidas well as possibility to convert between image formats
ZashSomeone did a thing for that for prosody too
zinidyeah, prosody also has such modules, but not sure about xupdate injection
ZashI'm not aware of any doing that, no
ZashWouldn't be hard
zinidyeah, it's trivial
zinidit was a contribution back then
archas left
zinidthe only problem is to make sure direct presences are also modified, it's a bit harder in ejabberd
zinidprobably in prosody this doesn't matter
ZashNot too hard, no
zinidwell, resending all direct presences is a problem, I need to solve it finally 🙂
archas joined
Zash 57% image/png
29% image/webp
14% image/jpeg
zinidwe recommend webp -> jpeg convertion
zinidI mean in ejabberd
stefandxmhas joined
Ge0rGhas left
Ge0rGhas left
zinidhas left
Ge0rGhas left
stefandxmhas left
waqashas left
waqashas joined
waqashas left
blablahas left
Ge0rGhas joined
Ge0rGhas left
goffihas left
zinidhas left
goffihas joined
ralphmhas joined
moparisthebesthas left
danielhas left
ralphmhas left
lskdjfhas left
lskdjfhas left
stefandxmhas joined
archas left
archas joined
Guushas left
Guushas joined
lskdjfhas joined
KevRight, GOK how many hours later, I think I'm finally up to date with LC reviews and feedback.
lskdjfhas left
marcGe0rG, one problem of combining user-invitation (account creation) and PARS is that both have different constraints regarding token lifetime
marca token for account creation should only valid for a single invitation whereas a PARS token could be used multiple times (see ML)
marccombining both would mean that we have to set N=1 for PARS as well
Guushas left
jubalhhas joined
jubalhhas left
lskdjfhas left
zinidhas left
lskdjfhas left
lskdjfhas left
danielhas left
lskdjfhas left
lskdjfhas left
jerehas joined
zinidhas left
lskdjfhas left
SamWhitedhas left
Ge0rGmarc: if you read the PARS XEP, you might find out that the default use case is N=1 😜
lskdjfhas left
lskdjfhas left
Guushas joined
lskdjfhas joined
marcGe0rG, yes, just read the ML and saw the idea of N > 1 and offline usage
Ge0rGmarc: obviously the token limitations need to be shared by pars and account invitation
marcGe0rG, yes, that's what I said ;)
Ge0rGYes, and how is that a problem?
lskdjfhas left
marcGe0rG, just liked the idea of offline usage and N > 1 for PARS
marcJust that ;)
jcbrandhas joined
lskdjfhas joined
Ge0rGI didn't like N>1 very much, but I can live with it
lskdjfhas left
lskdjfhas left
archas left
lskdjfhas left
tuxhas joined
zinidhas joined
lskdjfhas joined
danielGe0rG: wait didn't you introduce this?
archas joined
danielI vaguely remember me trying to convince you that we only need n=1
Ge0rGdaniel: wait. I didn't like N=infinity.
danielthere is only 0,1 and infinity
Ge0rGdaniel: but then you convinced me that 1 and infinity are the only two useful cases, or some such.
danielso everything >1 is infitiny
Ge0rGdaniel: but if we start out with an ad hoc command anyway, we can make it N=1
efrithas left
efrithas joined
danieloh right i wanted to make it time constrained to cover the use case of sending the same email to multiple recipients
lskdjfhas joined
lskdjfhas left
andrey.ghas left
debaclehas left
andrey.ghas joined
Ge0rGYeah, and I hoped that people expect invitation links to work only once
danielhas left
danielhas left
danielhas joined
marcGe0rG, as long as you can live with server-side PARS everything is fine :D
zinidhas left
lskdjfhas joined
lskdjfhas left
intosihas left
moparisthebestI missed the recent stuff, but wasn't PARS originally supposed to work if implemented by server OR client ?
lskdjfhas left
lskdjfhas left
Ge0rGmoparisthebest: yes. I still can see a sensible fallback for servers without support
mimi89999has left
moparisthebestI think that's the ideal situation
marcGe0rG, but that's a client decision and I would vote against it :]
moparisthebestrequiring server support immediatly puts widespread use off for years
Ge0rGmarc: you would vote against what exactly?
marcproviding user invitation on client-side as fallback
marcbecause it leads to different behaviour and might confuse users
moparisthebestso it's better to have no fallback and things just not work?
moparisthebestthat wouldn't confuse users
Ge0rG"why don't I have that invite button you are talking about?"
Ge0rGmarc: I'm not sure if you try to out-troll me or if you are serious...
marcIMO it is better to tell user why something is not available / possible instead of silenty change the behaviour
marcGe0rG, no, I don't waste my time with trolling
marcGe0rG, that's just my experience with XMPP/Jabber novices
Ge0rGmarc: so you want to teach users how what they want is impossible, instead of making it work in the 90% case?
marcGe0rG, client-side PARS is available in a single client
marc90 %?
marcWhat is for users with other clients, older versions etc.
moparisthebestso a "Sorry please tell your server administrator to enable PARS" is preferable to it just working?
Ge0rGmarc: even with manual approval, the invitation link is a great improvement of the user story
moparisthebestthat's how you get "I tried XMPP once, it sucks"
Ge0rGmarc: pars will work with your client, I just need to push one more button
moparisthebestmarc, if I had to guess, a single client is 90%+ of new users (conversations)
danielhas left
danielhas joined
marcmoparisthebest, I have lots of users with old Conversations versions
marcSame is true for Gajim
marcBecause your distro doesn't always provide the newest version
Ge0rGmarc: the nice thing about PARS is it's 100% backwards compatible
marcIt's just my experience with my users
Ge0rGmarc: so I really don't understand what's your problem
ZashFWIW Conversations having a server features list thing seems to work.
ZashI don't think normal users actually understand it, other than a list of checkboxes that they want to be all green
marcGe0rG, I wouldn't call it problem, just my opinion regarding UX and experience with non-pro-users
ZashAnd like, don't underestimate how much humans wants to collect imaginary internet points
Ge0rGmarc: I've implemented pars in yaxim, so it might have some 5000 users now. And it doesn't need users to migrate to another server or seeing "you are not allowed to do this, Dave"
lovetoxhas left
Ge0rGmarc: computers are supposed to do the work for their user, not to teach them how they are doing it wrong
ZashGe0rG: +inf
jubalhhas joined
jubalhhas left
jubalhhas joined
moparisthebestmarc what % of users use old clients vs what % use old servers I wonder
moparisthebestseems clients update much more often to me
zinidhas joined
ZashSurvey time?
jerehas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas joined
marcmoparisthebest, that's correct but implemting a feature on client-side because all the public servers suck is not a solution. Nobody will join the XMPP network without "standard" features which are not available on exactly those server you're talking about
marcSo the basic problem are the available servers and their operators
moparisthebestso if something can be implemented on the server with a sane on the client fallback, you should do it that way, imho
Ge0rGmarc: let's just shut down all public servers except conversations.im
Ge0rGIt's the only one supporting all conversations features anyway
marcGe0rG, you don't agree?
marcIt's hard to convince somebody to join XMPP because of privacy,decentralization, etc.
marcBut if you tell the users "Image sharing is not possible in group chat" they just laugh at you
moparisthebestno you want to convince them that it works better than anything else
zinidhas left
moparisthebestand uh, wasn't that image sharing in muc solved by http upload years ago?
marcmoparisthebest, yes, but lots of server don't support it
marcThat's my point ;)
ZashNothing matters, except network effects.
marcZash, not really, if you lack basic features you have no chance
ZashI'm pretty sure people will use garbage if it lets them talk to their friends.
moparisthebestso I had a question about that actually, http upload doesn't need server support right? at least from *your* server, like apps could hardcode httpupload.someremote.component
zinidhas joined
moparisthebestis that frowned upon or disallowed in XEPs or
ZashGarbage with a larger marketing department than what you have
Ge0rGmarc: so now you try to force users to move by telling them that their server sucks. They won't like that
Zashmoparisthebest: That'd be like Pidgin & co hardcoding proxy.eu.jabber.org as file transfer proxy
moparisthebestso what I imagined, not sure how legit this is or not
moparisthebestis what if xsf set aside some subdomains
moparisthebestand all clients could hardcode a fallback to that
moparisthebestand all servers could hardcode a local service serving that domain if they wished
marcGe0rG, sorry to say that but most server sucks... last time I ask somebody to send me a picture and I received a jingle file transfer (not working of course) and I forget that this user is on a shitty server...
moparisthebestare there downsides to that?
ZashData at rest is afaik legally different from data in transit (eg passing through a proxy)
Zashso, that would be horrifying
ZashAnd not something I'd wanna do if I were on the iteam
moparisthebestso possibly httpupload is a bad example because of that
moparisthebestbut what if it was a passthrough type component
moparisthebestI'm particularly interesting because I have something exactly like this in mind :)
SamWhitedAll of this is why you shouldn't try to get people to "use XMPP" or "use Jabber" you should get them to "use jabber.at" or "use <my-favorite-service>" and don't even tell them that it's "XMPP" or "jabber"
Ge0rGI don't even want to know what my users upload to http.
ZashHTTP passtrough? Still, look at how well proxy.eu.jabber.org is doing
lumihas left
marcSamWhited, +1
jcbrandhas left
marcGe0rG, of course I offered this guy to join my server...
Ge0rGmarc: of course you did.
moparisthebestZash, think of it as a bot type thing, you send it things, it sends them back
marcGe0rG, yeah because now this guy is in 2017 and can send images without configuring a STUN server or use other shitty solutions...
Ge0rGYesterday I migrated a user from jabber.org to yax.im because of Emoji in nicknames
marcGe0rG, :>
ZashRobot face strikes again, sorta
marcGe0rG, and that's just HTTP upload, let's not talk about E2E/OMEMO...
Zashhas left
Ge0rGmarc: you need to give the users positive incentives to switch, not force them
Ge0rGI don't even know why we are arguing here
ZashI don't even know what you are arguing about.
marcGe0rG, switch to XMPP or other servers?
Ge0rGZash: About whether PARS should have a client side fallback to compensate for outdated servers
marcAnd about the general idea to solve the "shitty server" problem with client-side workarounds
zinidhas left
ZashAren't we all doing that, solving problems by fixing them locally? :)
ZashIt probably doesn't matter as much if you manage peoples expectations.
Zashhas left
danielhas left
danielhas joined
Ge0rGZash: expectations like "XMPP sucks anyway"?
ZashIf people expect it to suck, then they can only have positive suprises! :)