pep., even though, all I can do is re-try really, because xmppoke doesn’t give useful logs in any way
danielhas left
jmpmanhas joined
Guus
jonasw: many failed tests on the webpage now.
jonasw
Guus, 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)
jonasw
I 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
Guus
jonasw, sorry, can't check now. Travellig.
jonasw
no worries
jonasw
now we’re getting quite a few sensible ones again
jonasw
it’s also possible most of what we saw was simply in progress
Guus
perhaps
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
Ge0rG
marc: https://mail.jabber.org/pipermail/standards/2016-June/031152.html (more on-topic in here)
Ge0rG
marc: 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
marc
Ge0rG, just the two posts?
Ge0rG
marc: there's a loooong thread going into 2017.
Ge0rG
marc: https://mail.jabber.org/pipermail/standards/2017-April/032599.html and https://mail.jabber.org/pipermail/standards/2017-May/032616.html
Ge0rG
with their respective "next in thread"
marc
Ge0rG, okay, maybe I find some time to read it
@Alacerhas left
waqashas left
@Alacerhas joined
Ge0rG
marc: you owe me half an hour of time anyway, for yesterday's discussion :P
waqashas joined
zinidhas left
marc
Ge0rG, :P
marc
Ge0rG, are you on 34c3?
Ge0rG
marc: I don't think so
marc
Too bad
jonasw
marc, the traditional XSF meetup is at FOSDEM
jonasw
the SUMMIT
marc
jonasw, okay, maybe I'll come to FOSDEM as well :D
jonasw
I 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
marc
Ge0rG, are you on FOSDEM 2018?
Ge0rG
marc: I might be able to make it to the SUMMIT. Maybe.
Ge0rG
marc: at least I've prepared a talk about what's wrong with XMPP ;)
marc
:D
marc
Ge0rG, but not submitted, right?
Ge0rG
marc: you can't submit to SUMMIT
Ge0rG
marc: the XSF summit is a separate conference taking place in the days before FOSDEM
marc
Ge0rG, ah
Guushas left
Guushas joined
marc
I was talking about FOSDEM submission :)
Ge0rG
marc: https://wiki.xmpp.org/web/Summit_22
jerehas joined
Ge0rG
marc: giving my talk at fosdem would be a huge disservice to the XMPP community
marc
:D
Ge0rG
or I would end up with a reputation similar to Poettering :P
lovetoxhas joined
jonasw
he's fun when he crashes other peoples talks
Ge0rG
I've crashed a talk about SCCS once. It was not particularly challenging
Flow
Ge0rG who gave the talk?
Ge0rG
Flow: I'm not naming names here, but it was at a conference venue known to you.
jcbrandhas left
Flow
schilling 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
marc
Ge0rG, almost everybody except you is voting for server-side implementation, is that correct? :D
Ge0rG
marc: I'm not opposed to server side implementations, but please have a look at bookmarks in PEP.
marc
the pep idea has some nice features
marc
Ge0rG, bookmarks in PEP? what do you mean?
Ge0rG
marc: the bookmarks xep recommends pep as the storage backend for a decade now, and there is no proper server support yet
marc
well, the PEP can not be used for user-invitation because it can not be limited
marc
this is not good for account creation :D
Kev
Ge0rG: No, that's just not true. You mean that Prosody doesn't support it, which isn't the same as there being *no* support.
edhelas
Kev +1
marc
but I like the idea of generating offline tokens
Ge0rG
Kev: last time I've heard that prosody completely lacks support, whereas other widely deployed implementations only leak your bookmarks to the general public.
Ge0rG
Kev: from a client interoperability perspective, that discussion is moot anyway.
edhelas
that's false
Holger
Ge0rG: Er, this is specific to bookmarks, and the reason is that the XEP is broken.
goffihas left
edhelas
whitelist support is quite great
Holger
Ge0rG: Daniel is currently trying to fix it. Once that happened, it will be fixed in the next ejabberd release, for example.
edhelas
Holger Daniel is trying to fix what ?
Holger
Well, I should say "probably" I guess :-) But I'm quite confident.
Ge0rG, ejabberd leaks your private pep nodes to the public?
Ge0rG
Kev: 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.
Ge0rG
Kev: now please try to convince me this won't happen to server-side-PARS.
daniel
i think one could implement bookmarks in pep on conversations.im
Ge0rG
daniel: isn't that why you are trying to fix 60 now?
daniel
Ge0rG, no?
Ge0rG
daniel: I'm sure this will be approved by the Conversations Council of Elders.
Holger
Ge0rG: Unless you configure the node with access_model=opoen, then of course it's not leaked.
Ge0rG
Holger: I'm sorry for being ignorant about 0060, but what's the default access_model?
Holger
Ge0rG: 0163 says "The default access model is 'presence'."
Zash
For PEP
Ge0rG
Holger: so bookmarks are only leaked to your contacts?
jubalhhas left
goffihas joined
edhelas
can we not change that to whitelist ?
Zash
edhelas: For PEP? That'd make it useless
edhelas
servers can also enforce access_model for some PEP namespaces
edhelas
the issue is that the user will have to know if the access_model is good somehow
Zash
I was intending to have some defaults for well known PEP nodes coded in.
Holger
Ge0rG: 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.
Zash
edhelas: That's what you use publish-options preconditions for
edhelas
okay
edhelas
never heard of it
Kev
And therein lies the problem.
Zash
But, it's like the most starred issue in the Prosody issue tracker ^^
Holger
Ge0rG: But clients can configure the node's access_model even without that spec fix, of course.
Zash
Mostly because it has its own marketing team, but still
Kev
publish-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
edhelas
ah, here's another piece of 0060 that I'm discovering today
Ge0rG
Holger: bookmarks is referencing 223 for over a decade now. Please don't tell me nobody noticed it's broken until now.
Zash
Ge0rG: I'm sorry, but nobody noticed that it is broken until now.
Holger
Ge0rG: I think I mentioned it on standards@ quite a while ago.
Ge0rG
So apparently nobody implementing servers cared enough about this spec, for over a decade.
daniel
i noticed about a year ago. i just didn't get around to write a PR
Holger
Yeah sure.
Zash
Ge0rG: Correct
Kev
Ge0rG: They didn't, because 49 for 48 worked fine and there was no reason to change.
Holger
If a spec is broken, blame server devs.
Kev
And 223 was meant to be a profile of 60, so no-one read 223.
Ge0rG
And 0060 is so mind-boggingly complex that nobody read that either.
Zash
Soooo, we should get around to finishing that 60 splitup
Ge0rG
So everybody just bails out on "*pubsub*"
jonasw
Ge0rG, that’s not true, I read it!
Ge0rG
And 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.
Holger
jonasw: Me too, but that doesn't help, because the text changes whenever you re-read it.
daniel
we should really revisit that hiring famous actors and actresses to make audiobook versions of XEPs
Ge0rG
daniel: you can't imagine how much time you need to spend to explain to them the corrent pronounciation of all the tech terms
jonasw
Holger, that was my impression too
edhelas
daniel :D Book 36 - Pubsub - Chapter 342 - Configuring your node, 64min
Holger
:-)
Ge0rG
edhelas: that title almost reads like a Bible verse.
Ge0rG
"And so saith Saint Peter: it shall be XML"
edhelas
0060 is a bit like the Bible, each people reading it have their own understanding
mathieui
and let’s not talk about the religious wars
mathieui
and their thousands of casualties
Zash
Don't mention the war
Ge0rG
Okay, 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"
moparisthebest
HAHAHA 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
moparisthebest
that needs to go in the implementation notes of 60 or something
jonasw
Ge0rG, where did we setjmp though?
Ge0rG
jonasw: just unwind enough stack to get back to PARS
mathieui
Ge0rG, I did notice
daniel
Ge0rG, in any case, as a council member you could read my two! PRs on xep60 and form an opinion on which one you prefer
Ge0rG
daniel: I suppose this is unavoidable.
Ge0rG
daniel: 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
Ge0rG
Could we please mandate that a server with IBR also MUST provide valid XEP-0157 contact info?
archas left
archas joined
Zash
Write a XEP
Zash
Info XEP on "Things your public server should support"
Ge0rG
you can't enforce info-xep's
uchas left
jonasw
Ge0rG, you can if you check it on s2sin :>
jonasw
and send a <policy-violation/> stream error back.
Zash
-xep 222
Ge0rG
jonasw: technically, I can. But if it's not official policy, I am not allowed to
Zash
-xep 223
Bunneh
Zash: Persistent Storage of Public Data via PubSub (Informational, Active, 2008-09-08)
See: https://xmpp.org/extensions/xep-0222.html
Bunneh
Zash: Persistent Storage of Private Data via PubSub (Informational, Active, 2008-09-08)
See: https://xmpp.org/extensions/xep-0223.html
jonasw
Ge0rG, that’s why the info XEP :)
Zash
Informational, 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
Holger
If a server stores groupchat messages into the user archive, the server would have to de-duplicate if multiple resources joined the room, right?
Zash
Yes
Holger
Fun.
Ge0rG
It will also be fun for the client to receive those messages without realizing it was a MUC
Ge0rG
not so bad for proper MUC messages, but MUC-PMs will be a PITA
Ge0rG
Are MUC-PMs to be stored in the user's MAM?
daniel
Holger, Zash: also outgoing and reflected
Zash
Makes purely append-only storage reeeeally hard
Ge0rG
Finally, the server devs are going to experience the joy of synchronizing a MUC history.
daniel
Fun fun fun. All for having an incomplete archive of the room
Ge0rG
Especially the ones calling for MUC messages in MAM.
Zash
I don't wanna!
Ge0rG
Zash: I don't see you complaining on standards@
Holger
Maybe the user archive should query the MUC archive to sync missing messages.
Ge0rG
Holger: awesome idea.
Ge0rG
And the MUC archive should just crowdsource the request to other participants' MAMs.
Ge0rG
Distributed storage!
Ge0rG
It's all in the cloud now!
Ge0rGwanders off, laughing weirdly.
moparisthebest
since the cloud is just other people's computers everything has always been there
jerehas joined
lskdjfhas left
lskdjfhas left
Zash
Maybe the clients could send MAM queries to each other!
Ge0rG
Zash: then we don't need MUC any more. Just have clients poll each other in a round-robin way to distribute history and messages
Zash
Ge0rG: Next, have them connect to each other instead of servers!
danielhas left
jonasw
Zash, somebody seriously suggested that a while ago
jubalhhas joined
Zash
jonasw: Was it me?
danielhas joined
jonasw
I don’t think so
jonasw
(and I’m referring to "Maybe the clients could send MAM queries to each other")
Zash
You could in theory do that among your own clients and have serverless MAM
Ge0rG
Zash: ChatSecure used to bundle a HTTP server, minidns and some other tech debt to allow for serverless messaging
Zash
WTF HTTP server?
Ge0rG
I don't remember any more the rationale for that.. picture sharing maybe? Or forwarding of the app APK?
Ge0rG
But I remember their stack was so high it resembled the tower of babel.
marchas left
daniel
Http over otr
daniel
For file transfer
jerehas joined
Ge0rG
right!
Zash
Why not p2p http. Like p2p proxy65 that already exists
Ge0rG
So should I implement XEP-0049 in yaxim now?
jonasw
Ge0rG, yes
Kev
I think client-only MAM is not at all stupid - and is probably the only sane thing to do in the world of E2E.
Zash
It wouldn't be too hard to sync bookmarks between PEP and private xml
jonasw
Zash, would be great to have that in prosody
Ge0rG
Kev: client-side MAM queries that get around E2EE are also stupid.
Ge0rG
Or at least notoriously hard to get right.
Zash
jonasw: Depends on PEP with configurable access models, which isn't quite there yet.
Zash
In theory possible to hard-code some nodes to be private
Kev
Ge0rG: Sure. Just needs a vector clock and the server to inject MAM IDs into every stanza, right? :)
jonasw
Zash, might not be the worst idea
blablahas joined
Ge0rG
Kev: I'm not quite sure what you are referencing, and I'm even less sure I can keep my sanity if you explain it.
Kev
Not worth thinking about. I'm just distracting myself from far too many hours worth of Council work.
Kev
I'd forgotten how much of the week Council takes.
Zash
Kev: Vector clocks? I thought blockchain was the hip thing for everyhing now?
Kev
Choose your poison :)
danielhas left
danielhas joined
jonasw
my 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.
jonasw
TL;DR: ignore <TYPE/>
daniel
Kev: 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
Kev
M-Link does, FWIW, although not in all circumstances.
jonasw
I’m pretty confident that having MUC groupchat in MAM is horrible
Ge0rG
I think that adding any MUC messages into local MAM opens up a can of worms.
Kev
I 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
Kev
So I'm not refusing to make the proposed change, but I'm not sold on it at the moment.
Ge0rG
Kev: could you please annotate your right-wrong statement with the content of the respective opinions, so others can follow?
daniel
It 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
Kev
I 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.
daniel
Sure the dedup issues can be resolved
daniel
But to what end? Almost all clients will throw the messages away or not request them
Kev
Dedup sounds like a somewhat strong argument.
Holger
"Incomplete archive" sounds stronger to me :-)
Kev
I don't think it's an incomplete archive, is it?
Kev
It's a complete archive of what the user has received in her live sessions.
Kev
It's incomplete w.r.t. to the MUC, but that's ok because the user wasn't in the MUC at the time.
Holger
Sure. We invented MUC MAM because users didn't perceive this as "ok".
Holger
I thought.
Ge0rG
users want a full MUC archive.
Kev
That's probably true, and one reason for MIXxing it up.
Ge0rG
I've heard that messages getting lost is the #1 problem with XMPP.
Kev
Could 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
Ge0rG
Today 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
Kev
Carbons are a *nightmare* for bounce handling.
Kev
If 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."
Ge0rG
Kev: 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.
Kev
Holger: But what when the carbons were delivered and the originals bounced? It's horrid.
Kev
Ge0rG: ^
Ge0rG
Kev: yes. That's exactly what happened.
Holger
Kev: Yes. Or when the user will receive the messages from MAM.
Holger
You can easily make the right decision simply by looking into the future.
Ge0rG
I had a nice conversation full of green checkmarks, and then *BAM!* the zombie exploded and it was all full of "✖ cancel: recipient-unavailable"
Kev
Holger: I'm not convinced it'd be easy, even then :)
daniel
The real jid annotation for non anonymous mucs also won't work if the archive is on the user's server
daniel
I've made all these arguments in my original mail by the way
Kev
All of them? I'd forgotten about dedup, in that case.
Ge0rG
It 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)
Ge0rG
So, what about storing MUC-PMs in MAM?
Kev
Those you certainly want in there, because they won't be stored anywhere else. That much I'm confident I'm not wrong about.
jonasw
Ge0rG, 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)
jonasw
Kev, 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?✎
Ge0rG
jonasw: in a multi-client scenario, there is no right way to handle MDR / error responses, in any order.
jonasw
Kev, 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? ✏
Ge0rG
jonasw: <x/> tags!
jonasw
Ge0rG, what’s wrong with MDR wins?
Holger
jonasw: MUC PMs are really bad regardless of MAM.
jonasw
Holger, no reason to make them worse by offering them to clients which don’t even know about the MUC
Kev
jonasw: The issue there is really clients not knowing that it's a MUC - and they do have that information available to them.
jonasw
Kev, so essentially clients need to support XEP-0045 to use MAM? :)
Ge0rG
jonasw: "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
Holger
jonasw: So don't offering them to clients who do know about the MUC is the obvious solution?
Holger
s/don't/not/
jonasw
Holger, I think so
Ge0rG
Kev: clients don't generally know which JID is a MUC
Holger
jonasw: "Jonas, you installed me this app and now I LOST MESSAGES!"
Steve Killehas left
Kev
Ge0rG: They can do, they only have to ask.
jonasw
Ge0rG, tricky, but then again, that other client which wanted to have them is offline, and should sync with MAM on reboot
daniel
I mean the dedup issue can be solved fairly easily by a simple store everything and blame the clients rule
Steve Killehas left
jonasw
Holger, we should disable MUC PMs in all clients.
jonasw
being polemic here :)
daniel
Plus nobody will notice because we will just discard messages anyway
Holger
jonasw: I would agree if you weren't polemic :-)
daniel
> jonasw: I would agree if you weren't polemic :-)
👍
jonasw
Holger, I may be even serious, I’m not entirely sure.
Ge0rG
Kev: that involves at least one connection over an unreliable network medium.
Ge0rG
jonasw: except not all clients support MAM.
Ge0rG
Kev: 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.
Ge0rG
I 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?
Zash
You have to say what the field does when you register it.
Ge0rG
when I register the field?
jcbrandhas left
jerehas joined
jerehas joined
Zash
Yes. In the registry for that. Publish-options?
Ge0rG
But I'm publishing an item, not registering a field.
Zash
Ge0rG: Do you want to know what each of those three terms mean or somethnig?
jonasw
Ge0rG, I hate things
Ge0rG
Zash: that, too.
Ge0rG
Zash: it just doesn't make any sense to me.
jonasw
Ge0rG, <publish-options/> uses a form with defined fields
Ge0rG
jonasw: right.
jonasw
the field registry tells you whether it’s METADATA, per-item OVERRIDE or PRECONDITION
jonasw
the sentence you quoted enforces that
Zash
preconditions makes the publish fail if the value does not match the node config
Zash
overrides changes the node config, but only for that item
Ge0rG
jonasw: when grepping the XEP for METADATA, I only find other metadata and the quoted sentence, not an explanation.
Zash
Ge0rG: "metadata"
Zash
Ge0rG: I think that might be what the stuff in Push is
Ge0rG
§5.4 Discover Node Metadata?
daniel
Ge0rG, it exists because you have to register all form fields and you might want form fields that are NOP
Ge0rG
or maybe Stanza Headers and Internet Metadata (XEP-0131)?
daniel
https://gist.github.com/iNPUTmice/7c52785ed69787516abb60e31703dbd2 describes how to use publish-options from a client perspective in case this helps
Ge0rG
daniel: thanks, maybe that will enlighten me.
jonasw
Ge0rG, https://xmpp.org/extensions/xep-0357.html#publishing Example 13. Server publishes a push notification with provided publish options
jonasw
I think that’s an example of metadata
jonasw
it is neither a precondition nor a per-item override✎
jonasw
it is neither a precondition nor a per-item override of configuration ✏
jonasw
but something which is used by the pubsub service to do things
Zash
Do Things™
Ge0rG
okay, 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?
Zash
Yes
jonasw
Ge0rG, yes.
Ge0rG
Can't they just write that into the XEP?
Zash
It would be nice to split that into three different forms.
goffihas left
Zash
Buuuuut uh
daniel
fwiw one of my PRs gets rid of override
Ge0rG
Zash: I presume "But backward compat"
Zash
Ge0rG: p much
Ge0rG
now I need to understand what "node configuration" is.
daniel
because it was never used we can savely removeit
Holger
Or just ditch METADATA and OVERRIDE.
Zash
Altho since nobody used any of that until daniel started doing it with OMEMO ...
Zash
Holger: And ditch PubSub in Push entirely?
Holger
Zash: 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
Zash
Altho it is mentioned by 222 or 223, which nobody supports.
Zash
So, nm
Holger
Zash: push says I can add arbitrary custom data. 0060 forbids that.
Zash
Hnng
daniel
Zash, the push xep is not really an issue because that particular pubsub service doesn't have to annouce publish-options and all is good
daniel
put we can register that one push publish-options keyword as metadata if you prefer that
Holger
Yes, it is just not a PubSub service.
daniel
it's just the app server sort of accepting one pubsub like command for what ever reason
Holger
As you can't use a standard PubSub service for this anyway, it doesn't matter indeed.
zinidhas left
Holger
daniel: ChatSecure uses different fields FWIW.
daniel
Either way it doesn't conflict wit the wording in xep60
tuxhas joined
jjrhhas left
Holger
Well but only because this is not 0060-PubSub but a 0357-specific protocol with PubSub-like syntax.
danielhas left
Holger
This still annoys me but admittedly it's a separate issue.
jjrhhas left
Ge0rG
0357 is overly complex, isn't it?
jubalhhas joined
daniel
You just couldn't run a pubsub service and an app server on the the jid
daniel
Not sure why one would want that
Holger
Ge0rG: 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.
Holger
daniel: 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
jonasw
okay
jonasw
now for real: what is the most deployed avatar protocol currently?
Zash
Define deployed
jonasw
actually 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"
Zash
Make a thing that collects stats?
jonasw
I’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
Zash
Conversations popularity might have shifted it quite a bit for 84
Zash: User Avatar (Standards Track, Draft, 2016-07-09)
See: https://xmpp.org/extensions/xep-0084.html
jonasw
Zash, that’s good
jonasw
I don’t feel so alone anymore
Zash
Let's all just switch to xep 8 and {xep user profile}
Bunneh
Zash: 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
Zash
oh dear
jonasw
I‘d like to know for example how the heck to get georgs avatar
After performing an unscientific test, 27% of presence I see seems to have vcard-temp
jonasw
any jabber:x:avatar?
Zash
In a moment
jonasw
thank you very much for measuring
Zash
This CLI client tends to become unhappy about presence floods
Zash
rlwrap + long, colored lines => unhappyness
Zash
Also, FWIW, I did not count the cached presence I got, which has only <show> and <delay>
jonasw
I’m happy with a > 0 result in fact
Zash
Hm, but are these even comparable?
jonasw
why wouldn’t they?
Guushas joined
Zash
Not all servers send presence for offline contacts
Zash
Also some may have multiple online devices
Zash
I get '84 notifications from 37% of contacts
Zash
And like 2.4 presences per contact...
jjrhhas left
Zash
jonasw: 153 needs at least one *currently online client* to work (or you could poll vcards)
jonasw
Zash, does it?
Zash
While 84 needs at least one client to have published an avatar at some point in the past (modulo server persistence support or uptime)
jonasw
but 153 stores the avatar at the server, too?
jonasw
and there’s that presence notification thing
Zash
jonasw: Right. Notifications as defined by 153 requires an online client. Altho I suppose a server could inject the thing into offline presence.
Zash
Not aware of any doing the later
Zash
Could inject into online presence too
Zash
Server could even sync the avatar data between them. Mine does that for example.
jonasw
can we have that in prosody? ;-)
Zash
Write a plugin ;)
jonasw
how does your server do that?
zinid
jonasw, done in ejabberd like 10 years ago 🙂
Zash
zinid: which part?
zinid
Zash, both
zinid
pep<->vcard sync, and xupdate injection
goffihas joined
jonasw
zinid, neat, that probably explains why I’m seeing a lot of PEP avatars
zinid
as well as possibility to convert between image formats
Zash
Someone did a thing for that for prosody too
zinid
yeah, prosody also has such modules, but not sure about xupdate injection
Zash
I'm not aware of any doing that, no
Zash
Wouldn't be hard
zinid
yeah, it's trivial
zinid
it was a contribution back then
archas left
zinid
the only problem is to make sure direct presences are also modified, it's a bit harder in ejabberd
zinid
probably in prosody this doesn't matter
Zash
Not too hard, no
zinid
well, 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
zinid
we recommend webp -> jpeg convertion
zinid
I 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
Kev
Right, GOK how many hours later, I think I'm finally up to date with LC reviews and feedback.
lskdjfhas left
marc
Ge0rG, one problem of combining user-invitation (account creation) and PARS is that both have different constraints regarding token lifetime
marc
a token for account creation should only valid for a single invitation whereas a PARS token could be used multiple times (see ML)
marc
combining 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
Ge0rG
marc: 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
marc
Ge0rG, yes, just read the ML and saw the idea of N > 1 and offline usage
Ge0rG
marc: obviously the token limitations need to be shared by pars and account invitation
marc
Ge0rG, yes, that's what I said ;)
Ge0rG
Yes, and how is that a problem?
lskdjfhas left
marc
Ge0rG, just liked the idea of offline usage and N > 1 for PARS
marc
Just that ;)
jcbrandhas joined
lskdjfhas joined
Ge0rG
I 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
daniel
Ge0rG: wait didn't you introduce this?
archas joined
daniel
I vaguely remember me trying to convince you that we only need n=1
Ge0rG
daniel: wait. I didn't like N=infinity.
daniel
there is only 0,1 and infinity
Ge0rG
daniel: but then you convinced me that 1 and infinity are the only two useful cases, or some such.
daniel
so everything >1 is infitiny
Ge0rG
daniel: but if we start out with an ad hoc command anyway, we can make it N=1
efrithas left
efrithas joined
daniel
oh 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
Ge0rG
Yeah, and I hoped that people expect invitation links to work only once
danielhas left
danielhas left
danielhas joined
marc
Ge0rG, as long as you can live with server-side PARS everything is fine :D
zinidhas left
lskdjfhas joined
lskdjfhas left
intosihas left
moparisthebest
I missed the recent stuff, but wasn't PARS originally supposed to work if implemented by server OR client ?
lskdjfhas left
lskdjfhas left
Ge0rG
moparisthebest: yes. I still can see a sensible fallback for servers without support
mimi89999has left
moparisthebest
I think that's the ideal situation
marc
Ge0rG, but that's a client decision and I would vote against it :]
moparisthebest
requiring server support immediatly puts widespread use off for years
Ge0rG
marc: you would vote against what exactly?
marc
providing user invitation on client-side as fallback
marc
because it leads to different behaviour and might confuse users
moparisthebest
so it's better to have no fallback and things just not work?
moparisthebest
that wouldn't confuse users
Ge0rG
"why don't I have that invite button you are talking about?"
Ge0rG
marc: I'm not sure if you try to out-troll me or if you are serious...
marc
IMO it is better to tell user why something is not available / possible instead of silenty change the behaviour
marc
Ge0rG, no, I don't waste my time with trolling
marc
Ge0rG, that's just my experience with XMPP/Jabber novices
Ge0rG
marc: so you want to teach users how what they want is impossible, instead of making it work in the 90% case?
marc
Ge0rG, client-side PARS is available in a single client
marc
90 %?
marc
What is for users with other clients, older versions etc.
moparisthebest
so a "Sorry please tell your server administrator to enable PARS" is preferable to it just working?
Ge0rG
marc: even with manual approval, the invitation link is a great improvement of the user story
moparisthebest
that's how you get "I tried XMPP once, it sucks"
Ge0rG
marc: pars will work with your client, I just need to push one more button
moparisthebest
marc, if I had to guess, a single client is 90%+ of new users (conversations)
danielhas left
danielhas joined
marc
moparisthebest, I have lots of users with old Conversations versions
marc
Same is true for Gajim
marc
Because your distro doesn't always provide the newest version
Ge0rG
marc: the nice thing about PARS is it's 100% backwards compatible
marc
It's just my experience with my users
Ge0rG
marc: so I really don't understand what's your problem
Zash
FWIW Conversations having a server features list thing seems to work.
Zash
I don't think normal users actually understand it, other than a list of checkboxes that they want to be all green
marc
Ge0rG, I wouldn't call it problem, just my opinion regarding UX and experience with non-pro-users
Zash
And like, don't underestimate how much humans wants to collect imaginary internet points
Ge0rG
marc: 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
Ge0rG
marc: computers are supposed to do the work for their user, not to teach them how they are doing it wrong
Zash
Ge0rG: +inf
jubalhhas joined
jubalhhas left
jubalhhas joined
moparisthebest
marc what % of users use old clients vs what % use old servers I wonder
moparisthebest
seems clients update much more often to me
zinidhas joined
Zash
Survey time?
jerehas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas joined
marc
moparisthebest, 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
marc
So the basic problem are the available servers and their operators
moparisthebest
so if something can be implemented on the server with a sane on the client fallback, you should do it that way, imho
Ge0rG
marc: let's just shut down all public servers except conversations.im
Ge0rG
It's the only one supporting all conversations features anyway
marc
Ge0rG, you don't agree?
marc
It's hard to convince somebody to join XMPP because of privacy,decentralization, etc.
marc
But if you tell the users "Image sharing is not possible in group chat" they just laugh at you
moparisthebest
no you want to convince them that it works better than anything else
zinidhas left
moparisthebest
and uh, wasn't that image sharing in muc solved by http upload years ago?
marc
moparisthebest, yes, but lots of server don't support it
marc
That's my point ;)
Zash
Nothing matters, except network effects.
marc
Zash, not really, if you lack basic features you have no chance
Zash
I'm pretty sure people will use garbage if it lets them talk to their friends.
moparisthebest
so 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
moparisthebest
is that frowned upon or disallowed in XEPs or
Zash
Garbage with a larger marketing department than what you have
Ge0rG
marc: so now you try to force users to move by telling them that their server sucks. They won't like that
Zash
moparisthebest: That'd be like Pidgin & co hardcoding proxy.eu.jabber.org as file transfer proxy
moparisthebest
so what I imagined, not sure how legit this is or not
moparisthebest
is what if xsf set aside some subdomains
moparisthebest
*.component.xmpp.org
moparisthebest
and http upload registered httpupload.component.xmpp.org
moparisthebest
and all clients could hardcode a fallback to that
moparisthebest
and all servers could hardcode a local service serving that domain if they wished
marc
Ge0rG, 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...
moparisthebest
are there downsides to that?
Zash
Data at rest is afaik legally different from data in transit (eg passing through a proxy)
Zash
so, that would be horrifying
Zash
And not something I'd wanna do if I were on the iteam
moparisthebest
so possibly httpupload is a bad example because of that
moparisthebest
but what if it was a passthrough type component
moparisthebest
I'm particularly interesting because I have something exactly like this in mind :)
SamWhited
All 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"
Ge0rG
I don't even want to know what my users upload to http.
Zash
HTTP passtrough? Still, look at how well proxy.eu.jabber.org is doing
lumihas left
marc
SamWhited, +1
jcbrandhas left
marc
Ge0rG, of course I offered this guy to join my server...
Ge0rG
marc: of course you did.
moparisthebest
Zash, think of it as a bot type thing, you send it things, it sends them back
marc
Ge0rG, yeah because now this guy is in 2017 and can send images without configuring a STUN server or use other shitty solutions...
Ge0rG
Yesterday I migrated a user from jabber.org to yax.im because of Emoji in nicknames
marc
Ge0rG, :>
Zash
Robot face strikes again, sorta
marc
Ge0rG, and that's just HTTP upload, let's not talk about E2E/OMEMO...
Zashhas left
Ge0rG
marc: you need to give the users positive incentives to switch, not force them
Ge0rG
I don't even know why we are arguing here
Zash
I don't even know what you are arguing about.
marc
Ge0rG, switch to XMPP or other servers?
Ge0rG
Zash: About whether PARS should have a client side fallback to compensate for outdated servers
marc
And about the general idea to solve the "shitty server" problem with client-side workarounds
zinidhas left
Zash
Aren't we all doing that, solving problems by fixing them locally? :)
Zash
It probably doesn't matter as much if you manage peoples expectations.
Zashhas left
danielhas left
danielhas joined
Ge0rG
Zash: expectations like "XMPP sucks anyway"?
Zash
If people expect it to suck, then they can only have positive suprises! :)