XSF Discussion - 2017-12-11

🤦‍♀️

pep., which domain?

pep., even though, all I can do is re-try really, because xmppoke doesn’t give useful logs in any way

jonasw: many failed tests on the webpage now.

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

(the "=" between option and value are important)

I also wonder whether we get an interesting type of spam there

jonasw, sorry, can't check now. Travellig.

no worries

now we’re getting quite a few sensible ones again

it’s also possible most of what we saw was simply in progress

perhaps

marc: https://mail.jabber.org/pipermail/standards/2016-June/031152.html (more on-topic in here)

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

Ge0rG, just the two posts?

marc: there's a loooong thread going into 2017.

marc: https://mail.jabber.org/pipermail/standards/2017-April/032599.html and https://mail.jabber.org/pipermail/standards/2017-May/032616.html

with their respective "next in thread"

Ge0rG, okay, maybe I find some time to read it

marc: you owe me half an hour of time anyway, for yesterday's discussion :P

Ge0rG, :P

Ge0rG, are you on 34c3?

marc: I don't think so

Too bad

marc, the traditional XSF meetup is at FOSDEM

the SUMMIT

jonasw, okay, maybe I'll come to FOSDEM as well :D

I need to schedule that for me

Ge0rG, are you on FOSDEM 2018?

marc: I might be able to make it to the SUMMIT. Maybe.

marc: at least I've prepared a talk about what's wrong with XMPP ;)

:D

Ge0rG, but not submitted, right?

marc: you can't submit to SUMMIT

marc: the XSF summit is a separate conference taking place in the days before FOSDEM

Ge0rG, ah

I was talking about FOSDEM submission :)

marc: https://wiki.xmpp.org/web/Summit_22

marc: giving my talk at fosdem would be a huge disservice to the XMPP community

:D

or I would end up with a reputation similar to Poettering :P

he's fun when he crashes other peoples talks

I've crashed a talk about SCCS once. It was not particularly challenging

Ge0rG who gave the talk?

Flow: I'm not naming names here, but it was at a conference venue known to you.

schilling at CLT

Ge0rG, almost everybody except you is voting for server-side implementation, is that correct? :D

marc: I'm not opposed to server side implementations, but please have a look at bookmarks in PEP.

the pep idea has some nice features

Ge0rG, bookmarks in PEP? what do you mean?

marc: the bookmarks xep recommends pep as the storage backend for a decade now, and there is no proper server support yet

well, the PEP can not be used for user-invitation because it can not be limited

this is not good for account creation :D

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.

Kev +1

but I like the idea of generating offline tokens

Kev: last time I've heard that prosody completely lacks support, whereas other widely deployed implementations only leak your bookmarks to the general public.

Kev: from a client interoperability perspective, that discussion is moot anyway.

that's false

Ge0rG: Er, this is specific to bookmarks, and the reason is that the XEP is broken.

whitelist support is quite great

Ge0rG: Daniel is currently trying to fix it. Once that happened, it will be fixed in the next ejabberd release, for example.

Holger Daniel is trying to fix what ?

Well, I should say "probably" I guess :-) But I'm quite confident.

edhelas: https://mail.jabber.org/pipermail/standards/2017-December/034023.html

(I was assuming that this is Ge0rG's point.)

"specified perist_items"

small typo in the PR :p

Ge0rG, ejabberd leaks your private pep nodes to the public?

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.

Kev: now please try to convince me this won't happen to server-side-PARS.

i think one could implement bookmarks in pep on conversations.im

daniel: isn't that why you are trying to fix 60 now?

Ge0rG, no?

daniel: I'm sure this will be approved by the Conversations Council of Elders.

Ge0rG: Unless you configure the node with access_model=opoen, then of course it's not leaked.

Holger: I'm sorry for being ignorant about 0060, but what's the default access_model?

Ge0rG: 0163 says "The default access model is 'presence'."

For PEP

Holger: so bookmarks are only leaked to your contacts?

can we not change that to whitelist ?

edhelas: For PEP? That'd make it useless

servers can also enforce access_model for some PEP namespaces

the issue is that the user will have to know if the access_model is good somehow

I was intending to have some defaults for well known PEP nodes coded in.

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.

edhelas: That's what you use publish-options preconditions for

okay

never heard of it

And therein lies the problem.

But, it's like the most starred issue in the Prosody issue tracker ^^

Ge0rG: But clients can configure the node's access_model even without that spec fix, of course.

Mostly because it has its own marketing team, but still

publish-options isn't exactly well-specified, which is what Daniel's just brought up on list.

> 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

ah, here's another piece of 0060 that I'm discovering today

Holger: bookmarks is referencing 223 for over a decade now. Please don't tell me nobody noticed it's broken until now.

Ge0rG: I'm sorry, but nobody noticed that it is broken until now.

Ge0rG: I think I mentioned it on standards@ quite a while ago.

So apparently nobody implementing servers cared enough about this spec, for over a decade.

i noticed about a year ago. i just didn't get around to write a PR

Yeah sure.

Ge0rG: Correct

Ge0rG: They didn't, because 49 for 48 worked fine and there was no reason to change.

If a spec is broken, blame server devs.

And 223 was meant to be a profile of 60, so no-one read 223.

And 0060 is so mind-boggingly complex that nobody read that either.

Soooo, we should get around to finishing that 60 splitup

So everybody just bails out on "*pubsub*"

Ge0rG, that’s not true, I read it!

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.

jonasw: Me too, but that doesn't help, because the text changes whenever you re-read it.

we should really revisit that hiring famous actors and actresses to make audiobook versions of XEPs

daniel: you can't imagine how much time you need to spend to explain to them the corrent pronounciation of all the tech terms

Holger, that was my impression too

daniel :D Book 36 - Pubsub - Chapter 342 - Configuring your node, 64min

:-)

edhelas: that title almost reads like a Bible verse.

"And so saith Saint Peter: it shall be XML"

0060 is a bit like the Bible, each people reading it have their own understanding

and let’s not talk about the religious wars

and their thousands of casualties

Don't mention the war

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"

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

that needs to go in the implementation notes of 60 or something

Ge0rG, where did we setjmp though?

jonasw: just unwind enough stack to get back to PARS

Ge0rG, I did notice

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

daniel: I suppose this is unavoidable.

daniel: and still, I lack sufficient understanding of 0060 so far to be able to contribute an informed opinion. I'll work on it.

Could we please mandate that a server with IBR also MUST provide valid XEP-0157 contact info?

Write a XEP

Info XEP on "Things your public server should support"

you can't enforce info-xep's

Ge0rG, you can if you check it on s2sin :>

and send a <policy-violation/> stream error back.

-xep 222

jonasw: technically, I can. But if it's not official policy, I am not allowed to

-xep 223

Zash: Persistent Storage of Public Data via PubSub (Informational, Active, 2008-09-08) See: https://xmpp.org/extensions/xep-0222.html

Zash: Persistent Storage of Private Data via PubSub (Informational, Active, 2008-09-08) See: https://xmpp.org/extensions/xep-0223.html

Ge0rG, that’s why the info XEP :)

Informational, both. Why nobody looked at them?

If a server stores groupchat messages into the user archive, the server would have to de-duplicate if multiple resources joined the room, right?

Yes

Fun.

It will also be fun for the client to receive those messages without realizing it was a MUC

not so bad for proper MUC messages, but MUC-PMs will be a PITA

Are MUC-PMs to be stored in the user's MAM?

Holger, Zash: also outgoing and reflected

Makes purely append-only storage reeeeally hard

Finally, the server devs are going to experience the joy of synchronizing a MUC history.

Fun fun fun. All for having an incomplete archive of the room

Especially the ones calling for MUC messages in MAM.

I don't wanna!

Zash: I don't see you complaining on standards@

Maybe the user archive should query the MUC archive to sync missing messages.

Holger: awesome idea.

And the MUC archive should just crowdsource the request to other participants' MAMs.

Distributed storage!

It's all in the cloud now!

since the cloud is just other people's computers everything has always been there

Maybe the clients could send MAM queries to each other!

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

Ge0rG: Next, have them connect to each other instead of servers!

Zash, somebody seriously suggested that a while ago

jonasw: Was it me?

I don’t think so

(and I’m referring to "Maybe the clients could send MAM queries to each other")

You could in theory do that among your own clients and have serverless MAM

Zash: ChatSecure used to bundle a HTTP server, minidns and some other tech debt to allow for serverless messaging

WTF HTTP server?

I don't remember any more the rationale for that.. picture sharing maybe? Or forwarding of the app APK?

But I remember their stack was so high it resembled the tower of babel.

Http over otr

For file transfer

right!

Why not p2p http. Like p2p proxy65 that already exists

So should I implement XEP-0049 in yaxim now?

Ge0rG, yes

I think client-only MAM is not at all stupid - and is probably the only sane thing to do in the world of E2E.

It wouldn't be too hard to sync bookmarks between PEP and private xml

Zash, would be great to have that in prosody

Kev: client-side MAM queries that get around E2EE are also stupid.

Or at least notoriously hard to get right.

jonasw: Depends on PEP with configurable access models, which isn't quite there yet.

In theory possible to hard-code some nodes to be private

Ge0rG: Sure. Just needs a vector clock and the server to inject MAM IDs into every stanza, right? :)

Zash, might not be the worst idea

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.

Not worth thinking about. I'm just distracting myself from far too many hours worth of Council work.

I'd forgotten how much of the week Council takes.

Kev: Vector clocks? I thought blockchain was the hip thing for everyhing now?

Choose your poison :)

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.

TL;DR: ignore <TYPE/>

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

M-Link does, FWIW, although not in all circumstances.

I’m pretty confident that having MUC groupchat in MAM is horrible

I think that adding any MUC messages into local MAM opens up a can of worms.

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.

So I'm not refusing to make the proposed change, but I'm not sold on it at the moment.

Kev: could you please annotate your right-wrong statement with the content of the respective opinions, so others can follow?

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

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.

Sure the dedup issues can be resolved

But to what end? Almost all clients will throw the messages away or not request them

Dedup sounds like a somewhat strong argument.

"Incomplete archive" sounds stronger to me :-)

I don't think it's an incomplete archive, is it?

It's a complete archive of what the user has received in her live sessions.

It's incomplete w.r.t. to the MUC, but that's ok because the user wasn't in the MUC at the time.

Sure. We invented MUC MAM because users didn't perceive this as "ok".

I thought.

users want a full MUC archive.

That's probably true, and one reason for MIXxing it up.

I've heard that messages getting lost is the #1 problem with XMPP.

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?

(I did respond with mine already.)

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.

Carbons are a *nightmare* for bounce handling.

If you want to talk about server dedup handling being nearly impossible - Carbons can be taken out and shot immediately :)

"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."

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.

Holger: But what when the carbons were delivered and the originals bounced? It's horrid.

Ge0rG: ^

Kev: yes. That's exactly what happened.

Kev: Yes. Or when the user will receive the messages from MAM.

You can easily make the right decision simply by looking into the future.

I had a nice conversation full of green checkmarks, and then *BAM!* the zombie exploded and it was all full of "✖ cancel: recipient-unavailable"

Holger: I'm not convinced it'd be easy, even then :)

The real jid annotation for non anonymous mucs also won't work if the archive is on the user's server

I've made all these arguments in my original mail by the way

All of them? I'd forgotten about dedup, in that case.

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)

So, what about storing MUC-PMs in MAM?

Those you certainly want in there, because they won't be stored anywhere else. That much I'm confident I'm not wrong about.

Ge0rG, blame the client for taking type='error' responses into account after a MDR has been received.

(The real-jid thing is a problem with stripping elements, that I'm fairly convinced MAM shouldn't do too liberally)

jonasw: in a multi-client scenario, there is no right way to handle MDR / error responses, in any order.

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? ✏

jonasw: <x/> tags!

Ge0rG, what’s wrong with MDR wins?

jonasw: MUC PMs are really bad regardless of MAM.

Holger, no reason to make them worse by offering them to clients which don’t even know about the MUC

jonasw: The issue there is really clients not knowing that it's a MUC - and they do have that information available to them.

Kev, so essentially clients need to support XEP-0045 to use MAM? :)

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

jonasw: So don't offering them to clients who do know about the MUC is the obvious solution?

s/don't/not/

Holger, I think so

Kev: clients don't generally know which JID is a MUC

jonasw: "Jonas, you installed me this app and now I LOST MESSAGES!"

Ge0rG: They can do, they only have to ask.

Ge0rG, tricky, but then again, that other client which wanted to have them is offline, and should sync with MAM on reboot

I mean the dedup issue can be solved fairly easily by a simple store everything and blame the clients rule

Holger, we should disable MUC PMs in all clients.

being polemic here :)

Plus nobody will notice because we will just discard messages anyway

jonasw: I would agree if you weren't polemic :-)

> jonasw: I would agree if you weren't polemic :-) 👍

Holger, I may be even serious, I’m not entirely sure.

Kev: that involves at least one connection over an unreliable network medium.

jonasw: except not all clients support MAM.

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.

I just hope that you have a query manager that doesn't fire off the lookup for each individual message in the MAM flood.

> 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?

You have to say what the field does when you register it.

when I register the field?

Yes. In the registry for that. Publish-options?

But I'm publishing an item, not registering a field.

Ge0rG: Do you want to know what each of those three terms mean or somethnig?

Ge0rG, I hate things

Zash: that, too.

Zash: it just doesn't make any sense to me.

Ge0rG, <publish-options/> uses a form with defined fields

jonasw: right.

the field registry tells you whether it’s METADATA, per-item OVERRIDE or PRECONDITION

the sentence you quoted enforces that

preconditions makes the publish fail if the value does not match the node config

overrides changes the node config, but only for that item

jonasw: when grepping the XEP for METADATA, I only find other metadata and the quoted sentence, not an explanation.

Ge0rG: "metadata"

Ge0rG: I think that might be what the stuff in Push is

§5.4 Discover Node Metadata?

Ge0rG, it exists because you have to register all form fields and you might want form fields that are NOP

or maybe Stanza Headers and Internet Metadata (XEP-0131)?

https://gist.github.com/iNPUTmice/7c52785ed69787516abb60e31703dbd2 describes how to use publish-options from a client perspective in case this helps

daniel: thanks, maybe that will enlighten me.

Ge0rG, https://xmpp.org/extensions/xep-0357.html#publishing Example 13. Server publishes a push notification with provided publish options

I think that’s an example of metadata

it is neither a precondition nor a per-item override of configuration ✏

but something which is used by the pubsub service to do things

Do Things™

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?

Yes

Ge0rG, yes.

Can't they just write that into the XEP?

It would be nice to split that into three different forms.

Buuuuut uh

fwiw one of my PRs gets rid of override

Zash: I presume "But backward compat"

Ge0rG: p much

now I need to understand what "node configuration" is.

because it was never used we can savely removeit

Or just ditch METADATA and OVERRIDE.

Altho since nobody used any of that until daniel started doing it with OMEMO ...

Holger: And ditch PubSub in Push entirely?

Zash: Yes, currently it's non-standard anyway.

> Altho since nobody used any of that until daniel started doing it with that's probably true for a couple of things

Altho it is mentioned by 222 or 223, which nobody supports.

So, nm

Zash: push says I can add arbitrary custom data. 0060 forbids that.

Hnng

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

put we can register that one push publish-options keyword as metadata if you prefer that

Yes, it is just not a PubSub service.

it's just the app server sort of accepting one pubsub like command for what ever reason

As you can't use a standard PubSub service for this anyway, it doesn't matter indeed.

daniel: ChatSecure uses different fields FWIW.

Either way it doesn't conflict wit the wording in xep60

Well but only because this is not 0060-PubSub but a 0357-specific protocol with PubSub-like syntax.

This still annoys me but admittedly it's a separate issue.

0357 is overly complex, isn't it?

You just couldn't run a pubsub service and an app server on the the jid

Not sure why one would want that

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.

daniel: Yes there's just problem if the developer understands all that.

*no problem

okay

now for real: what is the most deployed avatar protocol currently?

Define deployed

actually used in the wild

"will make my client show an avatar with the highest likelihood"

"All of the above"

Make a thing that collects stats?

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

Conversations popularity might have shifted it quite a bit for 84

But, don't like Pidgin even support both?

pidgin doesn’t support PEP for sure

or medium-sure

Are you sure?

no

I’m confused

It does.

and frustrated

and hungry

I thought I saw Mood and stuff in there

Pidgin supports both vCard and PEP avatars.

And it publishes both.

okay, but not XEP8?

That's the second time you write XEP8

-xep 8

Zash: IQ-Based Avatars (Historical, Deferred, 2005-06-16) See: https://xmpp.org/extensions/xep-0008.html

Wat?!

Hah.

jonasw: I don't think so :-)

Now I'm possibly just as confused as you are

-xep 84

Zash: User Avatar (Standards Track, Draft, 2016-07-09) See: https://xmpp.org/extensions/xep-0084.html

Zash, that’s good

I don’t feel so alone anymore

Let's all just switch to xep 8 and {xep user profile}

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

oh dear

I‘d like to know for example how the heck to get georgs avatar

-xep 6

Zash: Profiles (SIG Formation, Obsolete, 2002-05-08) See: https://xmpp.org/extensions/xep-0006.html

because it doesn’t seem to be in either PEP or vCard

cc @ Ge0rG ^

-xep 154

Zash: User Profile (Standards Track, Deferred, 2008-04-18) See: https://xmpp.org/extensions/xep-0154.html

A data form?

pidgin shows much more avatars than jabbercat with 153 and 84.

could still be a bug in the 153 impl, but ...

I have this feeling that it uses the wrong namespace for something

Or am I confused?

Zash: User Profile (Standards Track, Deferred, 2008-04-18) See: https://xmpp.org/extensions/xep-0154.html

-xep 153 ✏

Zash: vCard-Based Avatars (Historical, Active, 2006-08-16) See: https://xmpp.org/extensions/xep-0153.html

After performing an unscientific test, 27% of presence I see seems to have vcard-temp

any jabber:x:avatar?

In a moment

thank you very much for measuring

This CLI client tends to become unhappy about presence floods

rlwrap + long, colored lines => unhappyness

Also, FWIW, I did not count the cached presence I got, which has only <show> and <delay>

I’m happy with a > 0 result in fact

Hm, but are these even comparable?

why wouldn’t they?

Not all servers send presence for offline contacts

Also some may have multiple online devices

I get '84 notifications from 37% of contacts

And like 2.4 presences per contact...

jonasw: 153 needs at least one *currently online client* to work (or you could poll vcards)

Zash, does it?

While 84 needs at least one client to have published an avatar at some point in the past (modulo server persistence support or uptime)

but 153 stores the avatar at the server, too?

and there’s that presence notification thing

jonasw: Right. Notifications as defined by 153 requires an online client. Altho I suppose a server could inject the thing into offline presence.

Not aware of any doing the later

Could inject into online presence too

Server could even sync the avatar data between them. Mine does that for example.

can we have that in prosody? ;-)

Write a plugin ;)

how does your server do that?

jonasw, done in ejabberd like 10 years ago 🙂

zinid: which part?

Zash, both

pep<->vcard sync, and xupdate injection

zinid, neat, that probably explains why I’m seeing a lot of PEP avatars

as well as possibility to convert between image formats

Someone did a thing for that for prosody too

yeah, prosody also has such modules, but not sure about xupdate injection

I'm not aware of any doing that, no

Wouldn't be hard

yeah, it's trivial

it was a contribution back then

the only problem is to make sure direct presences are also modified, it's a bit harder in ejabberd

probably in prosody this doesn't matter

Not too hard, no

well, resending all direct presences is a problem, I need to solve it finally 🙂

57% image/png 29% image/webp 14% image/jpeg

we recommend webp -> jpeg convertion

I mean in ejabberd

Right, GOK how many hours later, I think I'm finally up to date with LC reviews and feedback.

Ge0rG, one problem of combining user-invitation (account creation) and PARS is that both have different constraints regarding token lifetime

a token for account creation should only valid for a single invitation whereas a PARS token could be used multiple times (see ML)

combining both would mean that we have to set N=1 for PARS as well

marc: if you read the PARS XEP, you might find out that the default use case is N=1 😜

Ge0rG, yes, just read the ML and saw the idea of N > 1 and offline usage

marc: obviously the token limitations need to be shared by pars and account invitation

Ge0rG, yes, that's what I said ;)

Yes, and how is that a problem?

Ge0rG, just liked the idea of offline usage and N > 1 for PARS

Just that ;)

I didn't like N>1 very much, but I can live with it

Ge0rG: wait didn't you introduce this?

I vaguely remember me trying to convince you that we only need n=1

daniel: wait. I didn't like N=infinity.

there is only 0,1 and infinity

daniel: but then you convinced me that 1 and infinity are the only two useful cases, or some such.

so everything >1 is infitiny

daniel: but if we start out with an ad hoc command anyway, we can make it N=1

oh right i wanted to make it time constrained to cover the use case of sending the same email to multiple recipients

Yeah, and I hoped that people expect invitation links to work only once

Ge0rG, as long as you can live with server-side PARS everything is fine :D

I missed the recent stuff, but wasn't PARS originally supposed to work if implemented by server OR client ?

moparisthebest: yes. I still can see a sensible fallback for servers without support

I think that's the ideal situation

Ge0rG, but that's a client decision and I would vote against it :]

requiring server support immediatly puts widespread use off for years

marc: you would vote against what exactly?

providing user invitation on client-side as fallback

because it leads to different behaviour and might confuse users

so it's better to have no fallback and things just not work?

that wouldn't confuse users

"why don't I have that invite button you are talking about?"

marc: I'm not sure if you try to out-troll me or if you are serious...

IMO it is better to tell user why something is not available / possible instead of silenty change the behaviour

Ge0rG, no, I don't waste my time with trolling

Ge0rG, that's just my experience with XMPP/Jabber novices

marc: so you want to teach users how what they want is impossible, instead of making it work in the 90% case?

Ge0rG, client-side PARS is available in a single client

90 %?

What is for users with other clients, older versions etc.

so a "Sorry please tell your server administrator to enable PARS" is preferable to it just working?

marc: even with manual approval, the invitation link is a great improvement of the user story

that's how you get "I tried XMPP once, it sucks"

marc: pars will work with your client, I just need to push one more button

marc, if I had to guess, a single client is 90%+ of new users (conversations)

moparisthebest, I have lots of users with old Conversations versions

Same is true for Gajim

Because your distro doesn't always provide the newest version

marc: the nice thing about PARS is it's 100% backwards compatible

It's just my experience with my users

marc: so I really don't understand what's your problem

FWIW Conversations having a server features list thing seems to work.

I don't think normal users actually understand it, other than a list of checkboxes that they want to be all green

Ge0rG, I wouldn't call it problem, just my opinion regarding UX and experience with non-pro-users

And like, don't underestimate how much humans wants to collect imaginary internet points

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"

marc: computers are supposed to do the work for their user, not to teach them how they are doing it wrong

Ge0rG: +inf

marc what % of users use old clients vs what % use old servers I wonder

seems clients update much more often to me

Survey time?

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

So the basic problem are the available servers and their operators

so if something can be implemented on the server with a sane on the client fallback, you should do it that way, imho

marc: let's just shut down all public servers except conversations.im

It's the only one supporting all conversations features anyway

Ge0rG, you don't agree?

It's hard to convince somebody to join XMPP because of privacy,decentralization, etc.

But if you tell the users "Image sharing is not possible in group chat" they just laugh at you

no you want to convince them that it works better than anything else

and uh, wasn't that image sharing in muc solved by http upload years ago?

moparisthebest, yes, but lots of server don't support it

That's my point ;)

Nothing matters, except network effects.

Zash, not really, if you lack basic features you have no chance

I'm pretty sure people will use garbage if it lets them talk to their friends.

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

is that frowned upon or disallowed in XEPs or

Garbage with a larger marketing department than what you have

marc: so now you try to force users to move by telling them that their server sucks. They won't like that

moparisthebest: That'd be like Pidgin & co hardcoding proxy.eu.jabber.org as file transfer proxy

so what I imagined, not sure how legit this is or not

is what if xsf set aside some subdomains

*.component.xmpp.org

and http upload registered httpupload.component.xmpp.org

and all clients could hardcode a fallback to that

and all servers could hardcode a local service serving that domain if they wished

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...

are there downsides to that?

Data at rest is afaik legally different from data in transit (eg passing through a proxy)

so, that would be horrifying

And not something I'd wanna do if I were on the iteam

so possibly httpupload is a bad example because of that

but what if it was a passthrough type component

I'm particularly interesting because I have something exactly like this in mind :)

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"

I don't even want to know what my users upload to http.

HTTP passtrough? Still, look at how well proxy.eu.jabber.org is doing

SamWhited, +1

Ge0rG, of course I offered this guy to join my server...

marc: of course you did.

Zash, think of it as a bot type thing, you send it things, it sends them back

Ge0rG, yeah because now this guy is in 2017 and can send images without configuring a STUN server or use other shitty solutions...

Yesterday I migrated a user from jabber.org to yax.im because of Emoji in nicknames

Ge0rG, :>

Robot face strikes again, sorta

Ge0rG, and that's just HTTP upload, let's not talk about E2E/OMEMO...

marc: you need to give the users positive incentives to switch, not force them

I don't even know why we are arguing here

I don't even know what you are arguing about.

Ge0rG, switch to XMPP or other servers?

Zash: About whether PARS should have a client side fallback to compensate for outdated servers

And about the general idea to solve the "shitty server" problem with client-side workarounds

Aren't we all doing that, solving problems by fixing them locally? :)

It probably doesn't matter as much if you manage peoples expectations.

Zash: expectations like "XMPP sucks anyway"?

If people expect it to suck, then they can only have positive suprises! :)