XSF Discussion - 2024-02-02

fun question!

when a remote server is unavailable, is that type="wait" or type="cancel"? ✏

asking for an IRC transport which fails to join a room because it's failing to connect to an IRC network.

(and asking because a certain client seems to delete bookmarks of MUCs which fail to join with type="cancel", because that's considered a permanent error by that client, hence the bookmark is considered worthless)

jonas’: right, I would say 'wait'

prosody does cancel tho :)

(when I had routing issues to a domain the other day, I got `user@domain.example: cancel: recipient-unavailable` according to poezio)

I'm guessing that's what the RFC recommends for remote-server-not-found (which is understandable)

for recipient-unavailable the RFC recommends type="wait" ✏

here's a useless question: is xmpp a fediverse?

No

Yes

"Part of", rather.

jonas’: what made Prosody return that error?

MattJ, unreachability on layer 3

potentially one-way

We don't use recipient-unavailable for s2s issues

fun!

it definitely was an s2s issue though :)

Was it a component?

no

it was an individual, Zash.

I can probably try to dig up logs, but I expect to only have info level available

no, logs are gone

Zashs server recently had an error as the presented cert was different from the hash in the tlsa record, maybe that caused the error?

unlikely, I don't validate TLSA

(and the timing coincided perfectly with the moment when routing to my server was borked)

jonas’, now I'm at my laptop, I checked, and basically the only place we send cancel:recipient-unavailable is when a smacks client goes offline and we bounce errors for undelivered stanzas

wat

s2s smacks maybe? ✏

Ah, perhaps

(not enabled on my end though)

makes no sense all over all

Is there anything which permits to group/classify chats in different categories (for ease of access)?

okay, I hear that s2s stream management is enabled by default so it might've been that ✏

https://hg.prosody.im/prosody-modules/rev/9a7671720dec#l1.104 I don't see XEP-0198 say anything about errors, but then I might not be awake yet

manday, 30 XMPP developers are currently in a room in Brussels discussing how to do that

> manday, 30 XMPP developers are currently in a room in Brussels discussing how to do that and just a few minutes after I asked the question! I'm much flattered by the effort! 😆 ↺

😃

manday: you mean to group your own chats in your client? there are roster groups and a few clients support these for channels as well

I suppose, singpolyma - that's not the topic the 30ish are discussing, then?

I think the discussion is more about grouping them for public consumption vs grouping for yourself. but it's a big topic with lots of discussion

I see. For the usecase I have in mind, the grouping could be "suggested" for public consumption while users eventually choose themselves.

right, so that kind of flexible thing is under discussion

XEP-0050 examples are a bit weird. Example 14 for example doesn't provide an action, even though the previous example says it should be either prev or complete.

hmm, yes, example 14 looks non-compliant

note that examples are non-normative. but this should be fixed

Ta. Just wanted to confirm I don't misunderstand things. Ta

hmm, maybe not.

4.1 says execute is the "default value" so maybe leaving off action is technically allowed

Ah.

yeah, and schema says optional

so I was wrong. if not present it's the same as specifying execute

still maybe a bad example, but there it is

Right. That makes sense

that xep50 execute topic pops up once every few years ✏

generally for an interactive use case you don't use action=execute at all

flow, good to know :D

Tobi, the lastest version (1.3.0) of the xep did add some clarification, but I am sure we could still improve here

so if you are currently implementing xep50 things, and have an idea on how to improve the xep, then please share :)

Hello, a quick question: XEP-333 is still the way clients exchange information about who read what? There is nothing that made it obsolete?

blue: correct

If I explicityly subscribe a contact's PEP node. And then send presence without +notify. Should the server unsubscribe me from that node?

I don't think so? explicit subscribe takes priority, surely

So the server would have to store the subscription mechanics together with each subscription.

I sense an implicit MAY

😀

Either way the 0115 optimization goes quite besides today's IM use cases in my book. You typically want persistent subscriptions anyway, who cares about avoiding the one-time subscription cost per contact. What you want to avoid instead is the last notification spam on session creation (i.e. we need roster versioning for PEP), no?

I wouldn't complain about an opt-in receiver side filtering and forking method

(moving this discussion from summit channel) pep., Mari0: so an informational XEP about privacy, what users should expect, data minimization, best practices etc (even a "some people think if you follow these you might be GDPR compliant" note) would be fine, I'm just super against a server disco feature for "I'm GDPR compliant"

A XEP for *users*?

Well, to summarize to client authors what to tell users maybe, I mean it already exists spread out among all the XEPs and RFCs

that would work better imo if it was guidelines that govern: 1. what xeps xsf accepts 2. what clients/servers it lists

moparisthebest, wanna ressurect the ToS protoXEP I once wrote?

jonas’, "pep.> Somewhat related, someday when I find the energy again I'd probably revive the ToS attempt" :)

:)

moparisthebest, I'm done with this topic for now, tired of your pessimism. Not eveyrone is bad, evil, what have you. Really

Stay in your world where you trust no one alone

> Well, to summarize to client authors what to tell users maybe, I mean it already exists spread out among all the XEPs and RFCs I think pointing them to https://snikket.org/app/privacy/ or making one for your client is where to point that ↺

> moparisthebest, I'm done with this topic for now, tired of your pessimism. Not eveyrone is bad, evil, what have you. Really pep.: Where are you seeing pessimism ? I'm not saying any of this ↺

To quote myself from the summit channel: > You can do everything right, follow every best practice, and still leak data > The only way to guarantee that I don't leak your data is for you not to send it to me in the first place > Therefore the "solution" is to send me the bare minimum, and clearly communicate to users what exactly that is and the risks

I'm interested in real solutions, not empty promises, empty apology emails when data is inevitably leaked, or potential fines paid to govts that don't help users...

"Literally nothing stops an evil server from advertising GDPR compliance and then just doing whatever they want with the data"

Yes, that too, but it's an aside, not the real problem

It's everywhere you go and I'm tired of it

Again no idea what you mean

Whatever

Agreed

Literally nothing stops an evil government from advertising peace and then just selling weapons all over the world. But we, te people want peace and a law who promote peace is our allie.

In the case of personal data protection we don't have only al written principle of law but compulsory norms and if you don't respect them there are sanctions. ✏

Only in the EU (the EU can't do anything to me) and even then it doesn't actually help users

this is getting off-topic

how to write a xep? are there any guidelines? :-)

Mari0, https://xmpp.org/extensions/xep-0143.html

Mari0, XEP 0001 is also relevant to some extent

okk thx

Mari0, also look at other XEPs for inspiration

> how to write a xep? are there any guidelines? :-) Generally, try to find a similar one, copy+paste+change it :) ↺

thank you I'll ask for help if needed

We can do quite a lot sensible actions to aid with GDPR compliant deployments of XMPP. But it needs a bit of merging the technical with legal.

certainly

the ToS ProtoXEP back then was a start

just needs someone to pick it up again

. ✏

for those who don't know where it is: https://xmpp.org/extensions/inbox/tos.html

> We can do quite a lot sensible actions to aid with GDPR compliant deployments of XMPP. But it needs a bit of merging the technical with legal. it's a great challenge to me :-)

I don't see anything wrong with the TOS protoxep at first glance

scour the archives to figure out why it was rejected

IIRC it was because of the embedding of ad-hoc or so

One thing I wouldn't want in any case if enforce it via compliance suites and the like. Either have a GDPR-specific document and that's it, and other legislations may want to have their own, or have a somewhat generic thing that can be encouraged via regular channels.

TOS should be generic enough to work with any legal framework, supposing that legal framework deems the consent mechanisms in there sufficient

fwiw I'm ok without a consent mechanism first I guess, or having it optional (I haven't reread the spec yet)

Informing users is already a good thing

I think informationality should be possible

maybe it needs a slight modification of flows

pep.: btw next Cheogram Android release will support password argument in MUC join uri, for use with token invites

woo. I sent something in council@ today, not sure what happened with this spec

It's ok if it's just lost in translation

First of all we must be clear in what role and for what audience we write. The GDPR knows 'data subjects' (about who the data is processed), 'controllers' (responsible for the processing of the data) and 'processors' (doing work on behalve of the controller). A server operator may depending of the setting (and some more nuance), be a controller or a processor. A controller has to do all the compliance work, a processor has the obligation to aid with that and to stick to what the controller has instructed.

pep.: I'm hoping to prototype half of it in prosody soon and probably issuing with ad hoc since that'll make one less thing for me to build

Yeah, adhoc is handy for technies but terrible UX imo

First obligation of the GDPR is to know what personal data is processed and stored for what purposes, for how long and what data is exchanged. Some of them are really straigtforward and obvious in XMPP, but some XEPs (like securite reporting) might take more consideration. It would be good to map the data of the RFC's and (a subset of the) XEPs to processings and purposes, this would already be the first big hit towards compliance.

Some XEP's might need some extra consideration, would be good to instruct some do's and dont's

Then is the question of how to inform the datasubjects...

(note asking permission would not be needed in 99% of the cases)

> know what personal data is processed and stored for what purposes, for how long and what data is exchanged Ignoring GDPR, this is super important for users to be made aware of And agreed that it's all "out there" but not very handy for client authors to gather and summarize

> Yeah, adhoc is handy for technies but terrible UX imo The UX can be whatever you want (including a custom UI for certain commrnds if really needed). Have your tried our implementation? It can be improved more I'm sure but I think it's getting there ↺

singpolyma, I don't believe in a generic adhoc UI. I know it's a thing but I'd rather have specific UIs per feature. And while one doesn't prevent the other, you have to admit many clients stop at that :)

I mean, as a technie it's ok to me, but I don't think that's what I would want in a client for all to consume

In general it's my goal do have enough UI building blocks that the "generic" UI is identical to the one I would build custom anyway. I just spec it in XML instead of in .. well in android it's XML either way I guess

>> know what personal data is processed and stored for what purposes, for how long and what data is exchanged > Ignoring GDPR, this is super important for users to be made aware of > > And agreed that it's all "out there" but not very handy for client authors to gather and summarize Not only for client authors but also for people running servers (aimed at EU inhabitants)

Only the client author knows what it can send

Fresh for the FOSDEM - the first release this year: https://xmpp.org/2024/02/the-xmpp-newsletter-december-2023-january-2024/ 🥳

emus: congrats

Suuuper, will forward it

Seve: we have also.much more to.mimic if you want

I do! Taking it over the comms room

kk