XSF Discussion - 2018-02-15

jjrh, yeah, threading comes up once in a while

there’s protocol support, but nobody has thought of a good UX which doesn’t break when not all clients participate

And how would you do the UI without getting in the way of the user?

yeah

all of that

What do you mean?

Seve, with what specifically?

'getting in the way of the user'

being more of a burden than it is useful

Ah, ok :)

Slack has threads, but I don't know how people use them.

for example by being confusing or by requiring a lot of UI interaction which isn’t necessary otherwise for little gain etc. etc.

Thank you, I understand now :)

i thought about the HTTP upload. I think i'm just gonna white list Authorize, Cookies and X-* Headers. if that's not enough to make your upload api work than so be it. and just white listing headers instead of introducing new syntax helps me to avoid a namespace bump.

But X-* is deprecated

ok. minus X- then. so holger has to live with putting his stuff in a cookie then

daniel, Expires?

if it doesn't go through council with these rules then so be it

jonasw, Expires? really?

yes; it could be signed in Authorization, but it would be telling the client how long the file will stay alive

Does it really need a (black|white)list?

I can live with abusing some header for my special use case. I still fail to see how this helps with security but meh.

https://www.dropbox.com/developers/documentation/http/documentation

are you kidding me

this is a single html page, without index, which contains *all* the API endpoints of dropbox?

so dropbox allows to use a query argument instead of an header, we’re good

(otherwise, it’d need Dropbox-API-Arg)

jonasw, do they even have preauthed urls?

daniel, dunno

that feels a bit un-dropboxy

somebody mentioned it yesterday

ok. expires, authorize and cookie it is then. but only because having three items in a white list sounds better then having just two

nextcloud seems to be a plain PUT normally. I think they assume some Cookie or something.

jonasw, yes i brievely looked at these apis before and none of them seem to support preauth/one time upload things anyway

so you probably wouldn't use them in practice anyway

true

unless your server knows your own dropbox password or something weird

yeah, S3 is probably the most relevant API thing then

jonasw, NextCloud is Authorization or Cookie (I checked yesterday)

S3 supports query string, including at least one of the clones I checked (minio)

In the case of Dropbox, it seems weird to me that the XMPP server would be the one that provides that service

Zash, in my mind you link your XMPP account with Dropbox (via a page served by the XMPP service)

A transport!

It gets OAuth-approved, and the credentials go into Authorization

Ah, a fun thing

Couldn't all this be done locally without XMPP?

Assuming you have some kind of dropbox client installed

I wonder if there are services where you don't know the GET location until you upload

e.g. with Dropbox you would upload, and then you have to share the file to create a link for someone else to download it

Get some NextCloud and Dropbox devs into a room and don't let them out until they present a standard-ish interface (android intent) for this

glhf

maybe we just leave the xep in experimental until someone actually writes a s3 or dropbox or whatever service

and then we'll know

Speaking of not knowing the location until after upload, I've got a bunch of things where the GET URL is dependent on the content of the files

Ok, well I at least want to do an S3 one soon. I don't have NextCloud to test with, and Dropbox requires some OAuth stuff

Something something Location header returns the GET URL?

Zash, that sounds very reasonable

ok. let's leave the xep experimental. you write the service with the location header (if the get url is omitted in the orignial slot response) and then we know if that works and change the xep

daniel, how about "omit <get/> to indicate that the <put/> request will return the GET URL via Location header"?

let me know if you have something ready Zash and i get you a Conversations build to test this with

daniel: There's my pastebin, q.zash.se

Tho it receives as POST

that's probably i quick fix. and it would of course need to annouce itself over http upload

*a

Hm

Doesn't seem to use Location tho

And now it does

does it also use PUT?

no

https://gultsch.de/files/xep-0363.html

Ge0rG, does that sufficiently address your concerns as council?

daniel, did you exclude newlines from the header values?

from a quick glance I can’t see that

jonasw, yes. in december already

maybe put that in the text above the example, too

done

daniel: reading now, also "especially the file ending intact" --> "extension" is a better word here

daniel: "MUST not" --> "MUST NOT"

daniel: I'd say that this scheme is still susceptible to idiot developers. Please just define optional <authorization>, <cookie> and <expires> elements.

> 07:22:50 daniel> i thought about the HTTP upload. I think i'm just gonna white list Authorize, Cookies and X-* Headers. if that's not enough to make your upload api work than so be it. > and just white listing headers instead of introducing new syntax helps me to avoid a namespace bump.

oh.

Idiot proof protocol design?

you don't technically need a namespace bump, you could work around it with caps.

daniel: please also add a point to the Security about the client potentially being exploitable to SSRF / https://cwe.mitre.org/data/definitions/918.html

A namespace for every SHOULD and MAY

Feature *

Zash: much better than just incrementing the version each time.

the current proposal is much better, but then you end up with the XHTML-IM Implementor's Fallacy

Except for the complexity explosion

better than before, that is.

I disagree 🙂

Holger: with what exactly?

With it being better than before. But more discussion won't help I guess.

Ge0rG, can you word that as a full normative sentence

daniel: yes, as soon as I find some time.

because i frankly don't understand the issue well enough to word that myself

i'm not really sure what the client should do about this though

if your wifi router is broken your wifi router is broken

unless we really want to enforce some same origin stuff

I think the most sane way is to prevent automatic re-requesting of slots.

> Zash> And how would you do the UI without getting in the way of the user?

Remeber Google Wave?

It was/is even XMPP based

Flow: Remember how I'm probably the most anti-Google person here? Guess how much time I spent trying Wave

Not much since you are anti google?

Or is it the other way around: Young neutral Zash once tried Wave years ago and never looked at google again?

I assume it required a Google account, which I refuse to get.

The code is still around if you want to give it a second chance: http://incubator.apache.org/projects/wave.html

Although the apache project retried 4 weeks ago :(

I read the specs. I meh'd.

Binary XML deltas in ProtocolBuffers over XMPP or somethincg

fancy

would anyone with a good overview of current client and server features be able to be available between 17:30Z and 18:30Z?

I’m talking to the university person who wants to establish some IM thing and they already have XMPP in mind. I’d like to be able to answer questions about specific things

Would be awesome if there is someone!

Am I awake then?

jonasw: sure. If you mention me I'm available. Not that I'm necessarily the expert in client and server feature availability. But I know _some_ things

cool

jonasw, I know some stuff, but I'll be in and out around that time. But a mention *might* work.

ok

jonasw: The magical time when most people are between work and home?

Zash, Home-office and settled-for-the-evening in my case.

I didn’t choose that time :(

jonasw, I'll be around

wee, a bunch of people :)

I'll be on a train at that time, without connectivity, sorry.

SamWhited: I think Security Considerations in 393 could benefit from a note about stack exhaustion, given you're suggesting recursion for parsing.

does it have a grammar by now?

Kev, MattJ would you be ok with annocing the mam preferences (at least the current default) in the disco accounts features (as a form)? if so i can prepare a PR for the XEP

What's the reason?

i want to do my offline purge only if it is set to !never

and maybe during initial account setup prompt the user to enable it

w/o having to do the extra round trip for the preference discovery

primarily the first thing though. the other is just a nice bonus feature one could do

can’t you interleave the preference discovery with other round-trips you have to do anyways?

for account setup e.g. when setting the avatar

or while the user picks the avatar or something like that

yes. that's why i said primarily the first thing

maybe I’m confused what the first thing is; is it the offline purge?

yes

what is the offline purge?

if so, same argument holds, isn’t there something this can be parallelized with? ✏

Zash, xep13

Zash, {xep 13} i presume ✏

Zash: Flexible Offline Message Retrieval (Standards Track, Draft, 2005-07-14) See: https://xmpp.org/extensions/xep-0013.html

I’m starting to get this right!

anyways, gotta run

jonasw, still traffic… and more blocking things before i can go online. it's more complicated in the clients code if I have to wait for two things (disco and preferences)

daniel, I don't feel too great about this for a number of reasons

and since it boils down to the XEP-0013 purge, even less so

I think that should be solved a different way - Prosody doesn't even support XEP-0013

Yet not sending offline messages to MAM clients is totally trivial and something I was planning to do anyway

and doesn't require bloating disco queries

MattJ: please add it to 313.

MattJ: also what we discussed regarding overlap of offline and MAM, and one of them being a pointer to the other one.

How do you know it's a MAM client?

Holger, MAM request before initial presence

I actually want preferences removed from 313 and split elsewhere, ideally.

Yeah, I think that came up a couple of times in LC feedback, I'm in favour of that

Also the pubsub stuff

As long as there is a mechanism for the client to distinguish whether MAM was actively enabled on this account or not.

Ge0rG: why do clients need to tell?

daniel: in the context of GDRP and generic data privacy considerations, a client should be able to tell the user that they give up their message contents now

Ge0rG: I understand that a client might want to discover their settings. I don't understand why they need to discover the servers default

daniel: let me rephrase that: the setting should be a tristate of "enabled / disabled / schroedinger"

daniel: so a MAM-enabled client can move from schroedinger to enabled, but not override disabled to enabled if the user disabled MAM once.

i'm against clients enabling that automatically anyway. if anything it should ask during setup

but yes i understand your argument now

during account setup? What if MAM is enabled later on? ;)

Kev: maybe I should just say 'iterate over' then. Also, serious question, is that still a security issue? Do any compilers not put stack guards in place?

Stack overflow is a thing, yeah. I think it's worth a security consideration suggesting limiting the depth of parsing.

Well, overflow/exhaustion, anyway.

XSF Board meeting time. Nyco, Ralphm and Martin sent apologies, that leaves you and me, MattJ

I'm here

Is there anything you'd like to discuss with the two of us present, MattJ?

I don't think I have anything

As this is the second meeting in a row that we're about to skip, I'd like to invite others to have input now. I'd hate for people to not be able to bring something up, because of our inability to convene.

anyone?

going once...

If there's anything, please feel free to reach out in private, anytime

let's try this again in one week, MattJ :)

+1

ok, thanks. I'll send out the non-minutes

unless we organise that high-bandwidth meeting in the meantime

agreed

Damn, I wanted to bring up something for Board.

Totally missed the meeting due to a conf call.

I wanted to re-ask for the creation of a SPAM WG, with work around the Manifesto to be performed

Ge0rG: I've seen various references to that renewed request in context of the manifesto mail thread. Would you mind pulling the re-request to form a team in a separate mail thread - perhaps include a proposal for a specific charter - for easy reference when we're going to discuss this?

I'm kind of missing the benefit of having a work team (a group of people dedicated to this specific effort) for this, as I'd think that you'd want to include _everone_, not a select group - but I'm not _against_ forming a team for just that.

(if that made sense)

I don't think we've formed a working group that actually met more than once or twice or did anything at all since I've been here. I like the idea, but it might be helpful if you could find people that are willing to be members, will commit to doing work, and someone who can herd the cats when they don't show up first.

(as in, for things like iteam, or scam, it makes sense to me to be able to address a specific group of people. I'm not immediately seeing that for spam)

SCAM might be the exception, because it has a cat herder named Guus.

well, if infra is broken, you know to talk to iteam

but that said, if just rubber-stamping a team helps the effort, I'm not against it.

I think SCAM is different because it is more involved with the running of the XSF

That's true, it is rather different.

It has allocated budget, etc.

Anyways, I'm not against it (not that I have any say, this is a board matter), it might be helpful if you found people first or wrote a charter though.

The mandatory TLS manifesto did not have a working group - in fact it had almost nothing to do with the XSF, except possibly a blog post mention

iteam is pretty involved with running the XSF too ;)

But I think a SIG is probably more appropriate than a WG.

You don't want (I think) a formally-approved membership.

Or to only allow XSF members.

I'm fine with a SIG as well.

oh, I didn't even realize we had a different concept for WG; I assumed Ge0rG meant SIG.

I didn't know either.

We have SIGs and Work Teams.

Iteam and SCRAM are Work Teams. standards@ is a SIG.

Is standards a SIG? (seems silly to have an organisation who's purpose it is to manage standards, to have a SIG for that)

it thought that SIGs were the often time-limited groups for things like IOT spec advancement?

we're listing teams in the side-menu here: https://xmpp.org/about/xsf/editor-team

(we should restructure that a bit)

but I'm not seeing references to our SIGs on the website. Are they defined by XEPs?

(https://xmpp.org/about/xsf/bylaws section 8.2)

Reading that, a SIG makes more sense than a WT for SPAM.

but, do we keep a list of what SIGs we currently have active?

jonasw, the best way I can think of to do threading is to basically have a '+' next to a top level message and then reply in that context. When someone comments to that thread you bring that top level message to the bottom. (similar to how email threading is displayed in many mail clients)

Guus: do you know a JID for Paweł Ścibiorski from the Summit? I need more information from him in order to complete his reimbursement...

peter, yes. alameyo@igniterealtime.org

thanks!

you'll also find him in open_chat@conference.igniterealtime.org pretty much every day.

k

I'm not sure how things would work for clients who don't support threading - it would be confusing for people with clients that support threading.

Since their 'reply' would not be tied to any thread.

jjrh, how does that work with clients which do not support htat?

wouldn’t their replies look weird then?

Yeah that's the problem - if we are having a threaded discussion and bill replies with a client that doesn't have threading it's going to look weird to us.

yeah

and that’s why threading doesn’t work, in a nutshell

also, clicking to make a threaded reply is annoying

jonasw: what if you do heuristics based on this kind of reply?

heuristics fail :(

I'm not sure how to deal with that in a group chat without doing something weird like setting my username to jjrh391034 jjrh391035 in each message - so when you reply it would be to my username with the id and our clients would know to include it in the correct thread.

not all replies have a leading nickname mention :-)

assume they belong to the same thread as the last message

how far could you get with some graph based heuristics?

Well, things work when a popular client implements X and other clients are forced to implement X because that client has that.

if two (sub)groups of people seem to be talking mostly among themselves, uh, surely there are fancy algoritms that could tell you about that

well perhaps some sort of id appended to messages would work - If people with clients that don't support threading don't use the legacy way of inserting at least that id in their reply to a conversation well their message will be ignored / lost in the noise. Same way on a mailing list if someone just creates a new message to reply to a existing thread people will simply ignore it / not see it.

Zash, well what would be really neat is if one could find a way to essentially create a new MUC so the conversation moves there

did you just say that clients that don't implement this will implement it?

if all our messages end up with "Zash: #MESSAGEINGTHREADING_19230 , did you just say that clients that don't implement this will implement it?" for clients that don't support threading it's up to the user to include #MESSAGEINGTHREADING_19230 in their reply

That's not a great way solution though.

the user isn't going to do that

see, I didn't even

If you want an entirely separate room, then create one and invite people there

Surely it should be possible to send an invite to a room

I guess that's another way - if your client doesn't have threading support you get a message saying to join a room. That's a crummy solution too.

That's a more of a hard break tho, not what I imagine threading in a groupchat could be

I imagined that be more fluid

What would be neat - providing everyone had a client that supported threading - is to figure out when a thread should basically become a new chat room. Effectively 'off topic' discussions wouldn't matter, if we start talking about the new starwars movie in xsf it wouldn't be disturbance because that conversation would quickly be migrated to a new room.

What would threading even look like in a real time groupchat?

I imagine you would get pretty far by just placing more focus on messages in your current thread

like, fate down the others a bit

Yeah - I think I would do something like have the top level show up in the main room #threading_in_xmpp every time so we know chatter in that topic is going on. Same way when I check my email for a mailing list the thread with the most recent reply gets bumped to the top. If i'm active in the discussion (have a chat tab open) in the main chat I wouldn't see that thread.

I feel like even if every XMPP client supported threading and all of them did it reasonably well people would just not use it and things would mostly remain the way they are now.

People (including myself) get stuck in the ways they are used to.

from a UX perspective how would I even indicate who (what thread) I am replying to?

https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd

https://get.slack.help/hc/en-us/articles/115000769927-Message-threads

Although I would search for a video or something, to see more clearly how it's done.

what’s a usable client on Mac OS?

jonasw: adium and iMessage or so I heard. Not perfect though

jonasw: maybe Swift 4

Seve: I've used slack threading once after it was released, but nobody else in my team did, and the UX felt somehow wrong

Seve: so any news from KDE?

wat, matrix needs to poll if it can’t have google push foo?

that’s fun

What else would it do

hm? matrix protocol uses polling?

marc, unless they can use google/apple push

wtf?

yeah

jonasw, ref?

the settings in the app apparently

But http and json!

marc, something about "sync interval"

maybe this part: https://matrix.org/docs/spec/client_server/r0.3.0.html#syncing

jonasw, gajim and dino run on macos too right?

moparisthebest, I don’t know?

do they?

(gajim especially)

pretty sure yes

gajim almost certainly does

okay

Seve, so from https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd they are just joining another muc that happens to be a split window from the main muc ?

I think it is planned to make dino work on macos. Due to the general beta state of it there might be bugs

Gajim isn't a client I would recommend to newcomers.

Ge0rG, well 'works' is better than 'doesn't work'

and none of those other clients have mam/carbons I think

moparisthebest: well dino has both. But I hear it's still buggy

We need a client usability score

yes dino is fine too, I was mainly saying I'd recommend gajim over pidgin/adium all day

Sure. That I can agree with

can swift do MAM?

(and gajim)

Gajim can, Swift couldn't the last time I used it, but I know they've tried to modernize it a bit since then so it might be able to now.

SamWhited, released gajim or 1.0 beta?

I'm not sure, released I think. Give me a second and I'll see what I have installed

thanks

hmm, I thought the version I had on this machine did it, but I can't make it make a query (0.16.9) so maybe I did have the beta installed on my other machine or something

Ah, I see, it does have MAM, just not a version I support. 0.16.9 supports mam:0, 1.0.0 beta supports :1 and :2

I see

https://dev.gajim.org/gajim/gajim/blob/gajim-1.0.0-alpha1/ChangeLog

They dropped OTR too, nifty.

But support EME now for some reason… I will never understand the Gajim decision making process.

oh, no, that's not what I thought it was. Nevermind, that makes sense.

what’s wrong with EME?

yeah

I was thinking it was the old encryption mechanism that never got much adoption, I can't remember what it was called.

Ge0rG, +1 for client usability score. I'd factor in clients with support for XEP's which contribute to usability (message carbons for instance)

jjrh: I consider Carbons a MUST for many years now, but they are less urgent for single-client users.

OTOH, I don't have MAM in any of my actively used clients.

I get really annoyed with mcabber for not having MAM, it's a terrible experience.

If I want to catch up on something I have to use Conversations

SamWhited: you need leave mcabber 24/7, or make conversations use a negative priority.

(this is a statement about the quirks of XMPP, first and foremost)

I think it's problematic that a android client is one of the best XMPP clients

problematic is probably the wrong word.

jjrh: sad?

So let's be prepared for https://puri.sm/shop/librem-5/ :)

What's really problematic is that it's not *my* android client! 😁

"Partnering with Matrix Librem 5 is the first ever Matrix-powered smartphone, natively using end-to-end encrypted decentralised communication in its dialer and messaging app."

We need more people in the SCAM team!

has anybody ever looked at matrix and if their stuff is accidentally actually good? :)

Ge0rG, what's SCAM?

I mean their "reference" client is not but who knows about the protocol :p

SaltyBones, they rely on polling or an additional push protocol

marc: our marketing team, https://wiki.xmpp.org/web/Summits_Conferences_And_Meetups_team

wtf

Ge0rG, I want a hoodie!

NOW!

:D

marc: you should've gone to FOSDEM

I don't even want an XMPP hoodie. Sad. I'd rather have a Jabber one, but that will be 500$.

Ge0rG, yeah, damn :D

Ge0rG, how does the jabber hoodie look like?

marc: no idea.

The matrix web client is pretty

Actually there is a hoodie I want to have. Front: "Schroedinger's Chat" Back: "XMPP Group Chat 1.0 Protocol"

Ge0rG: I miss your name on the SCAM page ;)

marc: I rather want to be on the SPAM page.

I've looked at Matrix a bit; the clients they wrote are nice, the protocol isn't (well, it would be good for other things, but not for chat or anything realtime)

SamWhited: but http has won, together with Javascript and rest

https://matrix.org/docs/projects/try-matrix-now.html they have quite a few clients.

And XSS and https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=1107

Oh til that couch db is still a thing

I wonder if it does multi threading now

i dont understand

where are these nice clients

everybody seems to use riot which is pretty awful

Riot looks pretty and is something that is familiar to folks (looks like slack/discord/fb messenger)

Riot felt a bit cluttered at times, but it was pretty and worked more reliably than any XMPP desktop client I'd ever used up until that point.

And had more modern features.

i only know of video calls

but that s pretty awesome

http://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/ this stuff looks pretty nice

the best part about that is the GIF http://blogs.asterisk.org/wp-content/uploads/2017/09/cmp2k_1.gif

really takes you back

Ge0rG: your landing page should accept raw XMPP URIs

SamWhited, what's the problem with matrix's protocol?

It's a giant distributed graph protocol which will never scale very well

More or less everything syncs to everything else in a big mesh

What does it sync?

Message history between whatever servers are a part of the conversation. Having history in multiple places isn't bad, but the big mesh they build and all the polling they do is rather chatty.

So if two people chat it would only involve two servers, right?

Sounds benign and like xmpp...? :)

jonasw: does that mean that all native desktop client use polling? I assume Google Push is not available on Desktop