XSF Discussion - 2018-06-07

daniel, how did you ephemeral compared to the recent protoxep?

Isn't it basically just an extension element hint containing an expiry date?

(and can't that already be done with AMP? harhar ;))

flow, just with a simple <pretty-please-delete-me-after seconds="300"/> hint. and the counter starts when reading the message

isn't that essentially what the recent protoxep also does?

(not that exact syntax necessarily)

IIRC i've even read a sentence saying "counter starts after reading"

flow, well the proto xep does a lot more than that. putting the actual body in an extra element and stuff like that

yeah, I wonder what the authors reasons where for that

"security" i assume

I don't see any security possibly in there

because only clients that support burner message will be able to display that

flow, that’s my point

but eventually still store the whole message

that why i rather have some honest, simple hint

than a complicated mechanism

I see some merit in the break-backward-compat approach of the new XEP. But it also has some nice drawbacks

Ge0rG, care to share those merits?

daniel, flow: as the guys doing XML parsing, how hard is it to make use of this matryoshka wrapping? It's a bit like Carbons/Forwarded, but with individual message sub-elements in it instead of a whole message.

flow: mainly the point made by the XEP itself: it's a deliberate break with backward compatibility to ensure that display only happens on supporting clients.

As this is an optical thing anyway, that makes perfect sense

i’m really not a fan of the implied sense of security

Ge0rG: not familiar with the XEP but I always wondered why only body is encrypted, then for associated media tricks were invented (like checking if # is in right position instead of checking OOB tag), nested encrypted XML can be good for additional encrypted stuff... like jingle signaling... just my 2 eurocents

yeah trying really hard to make something "secure" what can never be

but we discussed this at length at the list

there is not really more to say

Implementation wise it wouldn't be a problem in Conversations. But the again this is not something I would put in mainline

daniel: I could argue that having FS-E2EE with all messages ending up stored in the clear on the user's device in a big sqlite is also just an *implied* sense of security.

And for my forks I rather stick with the approach I just described

Ge0rG, ahh right, there was indeed a few sentences motiviating that, and even a link to a previous "leak" of such messages

Security is always against a particular (group of) attack(s).

If the attack you care about is the stolen-device attack, clearly plaintext in an easily extractable form on the device isn't remotely secure.

But if the attack you care about is your server operator listening in or forging messages, plaintext on your device might be fine.

I can't see a well-defined attacker model in https://xmpp.org/extensions/inbox/ephemeral-messages.html#security

No.

And neither in https://xmpp.org/extensions/xep-0384.html#security

(nothing to read here, move along) ✏

Except it won't work. Not to actually improve security, and not even to make them look better.

Someone sent me PM in this muc to test iOS version of Xabber. I don't use client that supports PMs so don't know who it was. Pls message me directly.

😂

MUC is shit. :-)

I have MIXed experienced with it yeah

hah. ✏

Andrew Nenakhov: did you look at ejabberds muc sub?

I mean I understand that one can't wait for mix to be ready if customers need a solution now. But coming up with the third trimmed down version of muc seems a bit... NIH or whatever

daniel, Third? I think there's been more than that, but I can't think of them all.

Muc sub, muc light

Thats the two that came to life in recent years

daniel, Yeah, those two spring to mind. I just thought there was another, maybe from Tigase?

But yeah probably more...

daniel do you have plans to integrate MIX in Conversations on the long term?

edhelas: yeah I think it is moving in the right direction currently

I had my doubts at some point...

edhelas, Surevine implemented one version of MIX fairly closely, but since then the specification has radically changed.

> edhelas, Surevine implemented one version of MIX fairly closely, but since then the specification has radically changed. That's what's stopping me from implementing it now

I'm also happy with where it's going just that I'm wondering how it will fit in the Movim UI next to MUC

edhelas, I have been thinking about the UX implications of having two major Group Chat standards, too

also I think that the whole social part will maybe be rebased on MIX on the long term

Yeah clients side coexistence with muc worries me a bit too

Especially since Conversations is very tightly geared towards a conversation being either muc or 1:1

that's why I also want MIX to not only be a "MUC2.0" but be generic enough to handle all kind of real time "channels"

true

It's a boolean if you will in most of the code

uh, that’s going to be painful :(

same for Movim actually

I’m happy I started late enough to see this coming and having this abstracted away

Yeah, same. In 2008 ;)

edhelas: 'being generic enough to handle all kind of real time "channels"'' is definitely a MIX goal. If there are things you need NOT in the current MIX specs (which cannot be added on the edges) I'd really like to knowl. I'm working hard to simplify MIX, and push optional stuff away from the core. So I don't want to add new stuff, but we do need to make sure that generic use cases are addressed.

The whole 'shove whatever nodes you want in for additional data streams' thing is meant to allow this flexibility.

I don't think I'll live to see mix in reality. And speaking of nih, well, xmpp community had failed to come up with good group chat solution for how long, 20 years?

Did look at muc sub. Phrase MUC/Sub approach is compliant with existing MUC is a deal breaker

We need to kill it with fire.

we agree on that :)

jonasw: I don't

killing MUC with fire?

To me some parts of muc are 'good enough' to survive until mix comes along

right, I might’ve spoken too fast. there is some merit in keeping MUC around for IRC-style use, like this room.

Yes it's not perfect

I haven’t thought that through though.

oh, and yes of course, I wouldn’t want to build another thing between MUC and MIX until MIX comes around.

But I rather use that than I temporary work around

but in the long run, a world without MUC might be better ;-)

A solution such as MUC/Sub makes it work for WhatsApp groups without breaking compat. I prefer that over a hacky solution without compat (e.g. MUC-Lite).

I unconditionally agree on that, daniel

Yes and muc removes some of the annoyances

*And muc sub

does anyone implement muc sub on the client side?

I haven’t looked into it actually.

Smack I think

And we used parts of muc sub on a project as well

jonasw: p1 customers use it for their home-grown clients.

Ge0rG flow daniel Kev: message deletion is (of course) not enforceable in any way, it is more about the social aspects of privacy: you communicate 'this message has a short validity and a limited purpose' (a very appropriate message when, for example, sexting). It is nice to have a UI that supports that.

Steve Kille for example, the thing that I'd like check if there is a header/payload system (like on pubsub) then I can easily check if I have to load the content of the messages or if they are already cached (the content can be quite big)

winfried, I liked ralphm's example of sending someone a password

winfried: I understand the interest in marking a message as 'and then don't keep this long'. I don't mind standardising such a thing.

winfried: But claims that it's not a security thing/it's just social are at odds with the protoXEP that we discussed yesterday, which tries (and fails) to enforce things.

i think we understand that. the problem I have as a client developer is making sure my users understand that as well

For meta data like this, you can use SHIM

edhelas: You can easily do that on top of MIX.

in any case that shouldn't stop us from making a xep for that

In a similar way to pubsub avatars - splitting metadata and content for lookup.

okay :)

what about Nicknames, can we reuse https://xmpp.org/extensions/xep-0172.html#manage ?

I was pondering using the 172 payload, but I don't think it buys us much.

yeah it's not a big change

(I missed yesterdays discussion, sorry) then we fully agree ;-)

I'm not a big fan of publishing things using simple <message> queries, I'd like to have proper IQ (with error management and ids) then I can handle those publication back in my UI

You get error management and IDs with messages if you want them, just the same as IQ.

that's great, it's just a lighter syntax then, but do you think that it should be nice to specify that ?

Doesn't xep60 already do that?

yes, but with a different syntax and flow https://xmpp.org/extensions/xep-0060.html#publisher-publish-success

I think I'm missing context, can someone explain me in a few sentences what this is about?

in MIX 7.1.6, the message is published with id='92vax143g', this ID is not reflected in the answer so I don't know if the server actually ack the publication

ralphm, some are talking about teh Ephemeral Messages ProtoXEP, the others about MIX

edhelas: That's only for the main 'messages' node, which is intended for simple IM-style discussion.

If only MUC had threading!

But you have an infinite number of other nodes if you want standard pubsub semantics.

edhelas, The original id gets reflected to the "publisher" I think.

Dave Cridland ah yes indeed, <submission-id>92vax143g</submission-id>, I overlooked it

Dave Cridland: is that guaranteed?

And yes, the originator gets an ack on the original id.

ralphm: Yes, text just before example 30.

ralphm, In MIX? Yes.

MUST

Yay

well looks like it really improved since last time :)

on my side I'm planning to publish <entry xmlns='http://www.w3.org/2005/Atom'> in there

the fact that the nick and the jid are also generated from the server is a big plus

11:56:30 <--- You (Ge0rG) left the room (the MUC server is not responding) 11:56:30 ---> You (Ge0rG) joined the room 11:56:30 Warning: This room is not anonymous. 12:02:30 <--- You (Ge0rG) left the room (the MUC server is not responding) 12:02:31 ---> You (Ge0rG) joined the room 12:02:31 Warning: This room is not anonymous. 12:08:31 <--- You (Ge0rG) left the room (the MUC server is not responding) 12:08:31 ---> You (Ge0rG) joined the room 12:08:31 Warning: This room is not anonymous. 12:14:31 <--- You (Ge0rG) left the room (the MUC server is not responding) 12:14:31 ---> You (Ge0rG) joined the room 12:14:31 Warning: This room is not anonymous. 12:20:31 <--- You (Ge0rG) left the room (the MUC server is not responding) 12:20:31 ---> You (Ge0rG) joined the room 12:20:31 Warning: This room is not anonymous. 12:26:31 <--- You (Ge0rG) left the room (the MUC server is not responding) 12:26:32 ---> You (Ge0rG) joined the room 12:26:32 Warning: This room is not anonymous.

This is what happens when your other MUC-joined client goes out of battery and sticks in 0198 hibernation.

Schrödinger's Chat.

0198 should be killed with fire 🔥, too

Andrew Nenakhov: 0198 is a solution to a problem. Do you want to return to the problem being unsolved?

Maybe we should redo XMPP on top of stateless HTTP and WebSockets

Maybe with a distributed graph database in the background

a blockchain.

a cyber quantum blockchain.

In France, we just got “blockchain” put in the law!

It’s as hilariously useless as you may guess.

Ge0rG, very imperfect solution, we'll soon switch to better one.

Andrew Nenakhov: I've heard that already, almost a decade ago.

Not from me. I wasn't around 10 years ago.

Right.

Andrew Nenakhov, overview of how your solution would differ?

That doc I've given you access contains plan of what we do (xep-0XXX, xep-0PPP), it is actually implemented already on server (at least, it passes tests)

Andrew Nenakhov: didn't have the time yet, sorry :(

No problem, it's a rather long doc with 5 protocols all it Russian

It's not about the Russian, it's about the people who pay me to look at other documents.

: D

MattJ, overview: Disable offline messages Server stamps IDs and 'true' timestamps on servers Message delivery to server is controlled by receiving server Id by client (as a confirmation) Message delivery to clients is not controlled, client grabs recent state from server on reconnect and fetches required info from server.

So far looks to be working. 🤗

but that only works for <message/>s, right, not for <presence/> and <iq/>?

where's the part about reusing the previous session

No reusing previous session!

so a user with 1000 contacts will get a presence storm when their phone drops off the network for a moment?

No ) he won't.

why not? ✏

All we re doing is to make an extremely swift reconnect.

How does that work

swiftly.

I see

pep., client requests only those presences that we're changed since client last received presence.

Swiftly, yes.

So there's no offline message anymore, do you include MAM in there?

Or were you talking about the thing named offline messages

Mostly, it's modified mam,yes

We disable offline messages.

By the way, just remembered a very recent heated discussion where one guy was pressing me into 'we are in a 3rd generations of messengers, no longer need presences at all, we are always online'.

I'm surprisingly sympathetic to that view.

I understand where it comes from, but don't fully agree.

I think we should strip most stuff out of presence, make it account-wide instead in PEP.

We don't need per-device status messages.

And having one device DND, one Away, and one Free For Chat is a nonsense.

Andrew Nenakhov, à la Slack/Matrix/Mattermost etc, where everybody is always online? or is this just a side effect of no presence

pep.: But they're not.

Slack makes it very clear whether someone's online or not.

And that is useful.

It's just not useful to know that they're online on both their desktop and their mobile. Just that they're online.

They're still referenced in the channel even if they're not there anymore

As they are in XMPP with MIX.

Yeah, I don't like that either

related to MIX, how MIX is handling channels on JIDs, can I create a MIX channel on my own account ?

You can't.

Well, technically you could, but it would be a Bad Idea.

Much as you /could/ host a MUC room on your own JID, but it'd be a Bad Idea.

Kev, what does this feature bring exactly, always being in the room. What can you do that you couldn't without

pep.: See who belongs to the room, and sensibly have synchronisation between clients.

Kev, can you define "belong" in this context

pep., actively entered the room and was granted to do so before without actively leaving the room or being kicked in the mean time

Ok, what about "X entered roomY, closed his browser without parting, and never came back"

Dead user accounts is a problem everywhere, not just rooms.

The same is true in your roster.

but it wasn't the case in muc was it

It was in MUC too, just differently.

membership lists would have that issue

In MUC you ended up with stale affiliation lists.

Right.

True

But an affiliation list doesn't cause traffic.

Indeed.

Can we hyjack this room for a quick board meeting please?

never

brb 30s

Guus, pep. you have 30s to fight for the room :)

:D

hehe

Time's up

Ralphm, nyco, martin?

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

0. Welcome and Agenda

Who's here? What do you have?

Me. A house for sale.

> Slack makes it very clear whether someone's online or not. > And that is useful. +1 my managers are very unhappy when they don't see who is online on corporate xmpp server

Rough

Here

Meeting

(nothing except for the remainder of the privacy discussion we had last week)

All right.

Anyone heard from Martin?

(http://www.abelenstrasingel12.nl <-- it actually _is_ for sale)

nope

nor Nyco for a while

No - I can try to contact him before the next meeting

nyco is here

ah, missed that

MattJ: thanks

1. Minutes

Who can do them?

Here

I can do them

Cool

2. Continuation of the privacy discussion

Guus, take it away

ooh, me? 🙂

I'm struggling to remember where we left off last week

we discussed gdpr, and forming a team including I think Ralph, and Alex, to do an inventory?

Looks like we neglected to take minutes of the last meeting?

we neglected to take minutes of the last meeting.

here though: http://logs.xmpp.org/xsf/2018-05-31/#13:58:50

MattJ: yeah :-(

> [14:02:49] <Guus> Let's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.

I guess this was the primary action item

Yeah, we kinda ran out of time

nonetheless, we could do that now - assuming that no-one thought of an alternative approach since last week?

No, sounds good to me

I think in terms of mission statement, it should be somewhere along the lines of: make an inventory of all personal data we (= the XSF) collect, review our Privacy Policy (and make sure it gets back on the website), and see if there's work beyond that.

As for a mission statement (someone put this in proper English please), we're looking for a team that takes the lead in coordinating with board and work teams .. .what he said

:-D

Alex: are you around?

first stab: "The GDPR work team's mission is to a) make an inventory of all personal data that is being collected by the XSF b) review our Privacy Policy, and c) suggest improvements to both."

Anyone have comments on this?

sgtm

Wfm

As I mentioned last week, such a team will need to overlap with or work with iteam

MattJ, most likely - but I'd imagine that the team would ask specific questions to iteam, rather than have iteam worry about what info they should uncover.

Kev, you here?

Hmm?

I'm vanishing in about 15 seconds.

What's up?

gdpr / iteam wise, are you comfortable (with iteam hat) to help facilitate another WT to perform an inventory of what GDPR-related data we store in our systems?

(and/or can you suggest a better approach?)

(or intosi)

If someone asks iteam a straightforward question, I'm fine with us answering it.

I'm not fine with a question of "What stuff do we need to care about from iteam".

Kev: what personal data do we collect and how is it processed and stored?

I don't think we can answer that without being told what personal data are.

I need to vanish now, back in a few hours.

I'm assuming that GDPR-team and iteam can work on this together, from what I've read just now.

(where "personal data" is a very broad category, as defined in many legal documents, but roughly, every type of information that is related to a natural person or can be identified with one)

as for the member list of the work team: we agreed last week that it'd be wise to have Alex be part of that team.

Ralph, either you volunteered, or I volunteered you, iirc?

We have various people working on GDPR in context of https://wiki.xmpp.org/web/GDPR

assuming that these contributors meet the work-team member criteria (must be an xsf member, iirc), maybe invite them to join?

The wiki page lists Ge0rG, jonasw, pep., peter.waher & winfried

is anyone else interested?

Guus: you volunteered me

peter provided feedback on the minutes mostly

I can be on the team, I'm also on iteam, it will probably help

I haven't been able to review this page yet. The number of people here is pretty large.

I'm not saying that all of them aught to be on the team

but that group makes a pool of member candidates for the team

I personally would want involvement of Alex (our Secretary and keeper of company records)

agreed

Thanks MattJ

So we're coming up to the end of the meeting time... what members do we have so far?

In any case, we need to appoint members of this work team. Do we explicitly ask who wants to be on it?

Me, <potentially Alex>, <some people from the GDPR investigation that was done over the past months>

Yes, I think we need to ask them before we can include them :)

I'll keep an eye on things, but I don't think we need a bloated team

yeah, 3 or 4 should be more than enough members

Matt, could you ping Alex and the GDPR-gang, see if any of them is interested in joining?

Can do

we can that formalize next week.

Thanks!

(don't let that stop you from getting started, if the opportunity arises)

No, I'll aim to have a clearer idea of who's on the team by next week

wfm, thanks

Right, we install the Work Team next week.

With that:

3. AOB?

maybe ping Martin?

MattJ already said he was going to.

oh, sorry, missed that

nothing from me then

4. Date of Next

+1W

Next week, I'll likely be unavailable.

+1

but please continue without me

wfm

Guus: np, you can vote on list

. ✏

5. Close

Thanks all!

Thank you

I heard my n ame. I can’t promise that I can do a lot in the work team, so I’m hesitant to join

I'm 120% busy ATM

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

There's no such thing.

loadavg 1.2

You probably mean that you're not slacking unlike normal.

:D

Zash, for some reason cannot join prosody channel right now. quick question: when udpating from 0.9 to 0.10 and having modules_enabled = {"mam"; "carbons", "http_upload"}; how does one decide whether to use the 0.10 mam and carbons and not the ones from prosody modules?

Symlinks from a different directory is one way.

has muclumbus landed somewhere popular?

requests -- specifically first visits -- went up quite a bit in the last hour

no reffferrrerrrrrsss?

not in my logs

although I thought I had

but maybe people just strip that nowadays

I'm wondering if browsers stopped sending them.

not for site-local things

(I see those)

but maybe for cross-site things, or whatever this is coming from forbids it on the link

MattJ: what's the state of persistent, configurable pep in prosody?

> Andrew Nenakhov> +1 my managers are very unhappy when they don't see who is online on corporate xmpp server I don't understand how they get not to see who's online on xmpp

daniel, Link Mauve is working on it

MattJ, I think he's mostly waiting for more feature requests

no?

daniel, you just need: persistence, publish-options, access control (public, roster, closed) - anything else?

MattJ: well I'm asking in regards to bookmarks 2 which also requires multi item

I guess

multi-item is already supported (in mod_pep_plus, which will probably eventually become mod_pep)

Best case this makes it into the next major release in a couple of months

And behaves correctly in conjunction with +notify. Although I have no idea what 'correctly' means in that regard

treat any resource which publishes the corresponding +notify as subscribed?

(modulo ACLs)

is the prosody channel gone?

No

jubalh, https://chat.prosody.im/ as another way to access it

right, now it works

I see you on it though

pep., just connected now :)

Prosody itself got OOM'd yesterday by a test runner we were experimenting with ✏

jonasw: yeah but does it send the last item or only one item on login

Or none of the items

I think none or all makes sense

But pep is usually last

daniel, what does normal pubsub do?

Although the xep gives you some wiggle room

"it MUST generate a notification containing at least the last published item for that node and send it to the newly-available resource"

Right

so all items is the only option

(sensible option at least)

Interestingly that wouldn't necessarily give you retraction notifications, would it?

true, but sending a complete itemset gives you that implicitly

Oh right, <items>

pep., >I don't understand how they get not to see who's online on xmpp That's simple. I forced them to switch from gajim to early versions of Xabber for Web, which was, at times, weird and buggy. There was a period when presences were not supported at all

jonasw: yeah I'm not sure what the correct way is. But that's something we need to figure out and then prosody should do that. MattJ was asking about requirements and that's one of them even though we don't know yet how it will work exactly

Andrew Nenakhov, right, that's not an issue with XMPP then

And I hate bookmarks 2 a bit for doing the multi item thing

Running old and new 48 in parallel would have been so easy

But multi items really complicates things

If 0048 didn't exist, is multi-item better?

MattJ: I don't necessarily thing so

It's 'OK' but not sure why it would be better

Less data to send if one bookmark is changed

Zash: yes. But how many bookmarks do you have?

A bunch

~ 70 here

and fewer races

How often do you change your bookmarks from two clients at once tho?

But whether or not we think compat with 48 is more challenging we still need to figure out how we want to handle notifications

Zash, hibernated devices which can only apply changes later are a thing

Zash, also two clients receiving a MUC invitation and following it

or receiving a MUC invitation while modifying a bookmark

https://worldbuilding.stackexchange.com/questions/114033/how-can-santa-keep-his-lists-when-gdpr-is-around

you gotta love worldbuilding

jonasw: but if two clients publish the same bookmark at the same time multi item will give you two additional bookmarks. Single item will just make the last one win

Or does it take the jid as id?

Oh it does

daniel, oh, are you planning on supporting Bookmarks 2? So far I haven’t heard any compelling reason to do so. (I’m working on a mod_bookmarks for Prosody to synchronise between old and new 0048-style bookmarks, whether I will support Bookmarks 2 too is still unknown, and will mostly depend on whether clients do implement it.)

Link Mauve, it’s on my todo list for aioxmpp

jonasw, why?

reduction in raciness of updates of individual bookmark items

notifications for single items

both of which simplify things quite a bit

But it’s also missing a bunch of features which were used in 0048, such as shared room passwords (which I only use for gateways, but are still useful to support) or non-MUC bookmarks.

the latter is definitely a feature for me

MUC bookmarks have a functional relevance to every IM client supporting MUC, which are most

dealing with other bookmarks mixed into that is annoying (and not simplified by the one-object-for-all thing)

jonasw, I might add support for it at some point in Prosody, the goal being to have a single store for bookmarks, and to synchronise all two (three) versions for clients to only pick one favourite.

regarding shared room passwords, you can probably get that into the xep

One Store To Rule Them All?

The global blockchain graph database?

Link Mauve: It's on our todo list for Swift (bookmarks 2)