XMPP Summit - 2024-02-02


  1. goffi

    Hey I couldn't sleep and I've had a really short night yesterday, probably due to an excess of coffee. So I'll try to get some sleep back and I'll come later, at 12h the later so I can do and see the show and tell.

  2. ralphm

    FWIW I'm slow, too. At breakfast now

  3. Kev

    https://wondersheep.uk/scratch/spaces.md.txt was what I threw together last night. And yes, there's a reason I didnt send it to inbox.

  4. pep.

    Kev: end of the sentence missing in the intro? Second paragraph

  5. MSavoritias (fae,ve)

    also does this xep seem to not be based around hosting metadata of spaces on pubsub like the moxxy one?

  6. Kev

    It is not.

  7. MSavoritias (fae,ve)

    wouldnt it be easier to specify pubsub?

  8. Kev

    Or, well, kinda not, anyway.

  9. Kev

    > : end of the sentence missing in the intro? Second paragraph If that's the only thing you find missing, I'll be amazed :)

  10. Kev

    (Thanks)

  11. Kev

    (And fixed)

  12. MSavoritias (fae,ve)

    the moxxy one relies heavily on pubsub specifically also for "linking" so that each group chat can get notification about events from other groupchats https://codeberg.org/moxxy/custom-xeps/src/branch/master/xep-xxxx-communities.md#linking

  13. Kev

    I believe that the single service model is much easier. I think if we were to spec what I'm speccing as the baseline that's easy (relatively) to implement for servers, the 'link pubsub nodes to share configuration/administration state' thing is possible to implement on top.

  14. Kev

    https://wondersheep.uk/scratch/spaces.md.txt

  15. ralphm

    Just to confirm for those attending remotely: A/V ok?

  16. MSavoritias (fae,ve)

    yeah

  17. mathieui

    Kev, one unrelated remark to the XEP: where do we define the "Accessibility Considerations" in the standards process (I know that security considerations is defined in XEP 1)? And I think making that section mandatory in the future as well would be good, if only to have it say "there are no accessibility considerations here". Apologies if that got discussed in the last 10 years, I must have missed it

    πŸ‘οΈ 1
  18. singpolyma

    they already have to maintain all extensions in bookmarks2 anyway

  19. singpolyma

    so it's not a new requirement

  20. MSavoritias (fae,ve)

    second the accessibility being mandatory

  21. singpolyma

    except that as was said bookmarks already contains everything both open and not open (for chats that use bookmarks today)

  22. singpolyma

    πŸ–

  23. singpolyma

    hehe

  24. singpolyma

    so its for all chats ever open or closed

  25. singpolyma

    sounds like what we're talking about

  26. singpolyma

    you don't *have* to keep every thing but most chat UX does this, have a list of all archived chats etc

  27. singpolyma

    really no one closes chats unless they are spam πŸ˜‚

  28. edhelas

    Knowing that Bookmarks 2 have that nice <extensions/> thing where we could put those specific behaviors as well. I think the only one extension standardized for now is https://xmpp.org/extensions/xep-0469.html

  29. singpolyma

    I wouldn't call that standardized, but yes ;)

  30. singpolyma

    I am also using it for roster groups for bookmark items

  31. singpolyma

    and recently for open/archived and last read message data in some prototypes

  32. singpolyma

    (the latter using markers so no new xep for that)

  33. edhelas

    Yes sorry :)

  34. singpolyma

    (open/archived does need a xep eventually, and probably can be merged with pinned)

  35. singpolyma

    (since you can't be pinned and archived for example)

  36. singpolyma

    figuring out chats from MAM is *possible* but not complete (in case of expiry) or efficient, that's why we have roster/bookmarks

  37. singpolyma

    I wouldn't really say "open chats" so much as I would say "not archived"

  38. singpolyma

    open is "pinned" and pinned is "very pinned" πŸ˜‰

  39. debacle thinks of needles and pins

  40. debacle thinks of needles and pins: this MUC is needled, the other one is pinned

  41. singpolyma

    part of my thinks that archived or open or pinned could be a tag, execept for this fact that archived+pinned or archived+open etc should not be possible so it sort of feels like maybe we want an enum and not just a flat tag for that

  42. singpolyma

    if one client doesn't update for you, then that's at least no worse than today

  43. singpolyma

    more in clients less in servers to save everyone pain ;)

  44. singpolyma

    but as was said sever certainly can update pep nodes if desired

  45. singpolyma

    "rooms" 1:1 are just very small rooms

  46. singpolyma

    no such thing as obsolete items in a list of chats, not really. maybe spam/abuse you want to fully delete and not just archive but meh

  47. pep.

    > the space domain, MUC domain (if applicable) and PubSub domain (if applicable) be hosted within the same system so that access lists can be shared internally. It may later be extented to remove this requirement. I hope it's even possible to remove this requirement someday :/

  48. singpolyma

    pep.: why?

  49. singpolyma

    you want to host a single community on a bunch of servers?

  50. pep.

    Why not

  51. pep.

    I guess we still don't agree on what spaces are

  52. singpolyma

    I think that's the one thing everyone agrees on re spaces πŸ˜…

  53. singpolyma

    (that no one agrees what they are)

  54. edhelas

    > I guess we still don't agree on what spaces are And even if we specify it (and basically really complexify the whole thing) I'd be curious to see if servers and/or clients will actually bother dealing with that extra step. Personally I'd not.

  55. pep.

    It's not "an extra step"

  56. singpolyma

    edhelas: well, for a team/community chat client it's a pretty useful feature I think. but yeah, what UI you'll bother with in general purpose clients remains unknown

  57. pep.

    Also another question: What is "a spaces domain". Is it a collection (in the generic way, not PubSub way) of spaces? Does it need its own domain too? These items (results) can just be put anywhere in disco#items right?

  58. SavagePeanut

    I tihnk it's reasonable to think if a remote MUC or PubSub domain is added to the space it can be trusted with access lists and roles. Don't add it if you don't trust it :)

  59. pep.

    (since they would be disco'd after that anyway)

  60. singpolyma

    pep.: for the draft xep as written yes a collection of spaces. which seems like an odd thing to need to me, but I see it fits how some people think about spaces

  61. edhelas

    Are spaces a hacky way to have "PEP on MUC" in the end. Creating a space with a unique muc in it and attaching a few pubsub nodes (as "PEP ones") πŸ€” ?

  62. singpolyma

    at a protocol level we have pep on muc already, just no one has an implementation of it πŸ˜‰

  63. pep.

    I'm already starting to dread the specific domain requirement for no reason :x

  64. goffi

    Can we publish the node in read-only? I would like to send the link on Mastodon, as some people are following. I've tried "publish", but I could edit on the given link.

  65. singpolyma

    so solving it with a new thing that also no one implements is funny

  66. MSavoritias (fae,ve)

    i wonder if with mix they would just be another node next to the messages and participants nodes and such

  67. pep.

    edhelas, yeah I'd rather not reproduce MEP if possible

  68. MSavoritias (fae,ve)

    and yeah i agree seperate domain sounds horrible :/

  69. goffi

    publish the pad*

  70. MSavoritias (fae,ve)

    if i can implement it only on a pep/pubsub node then i am good :)

  71. MattJ

    I discussed with Kev this morning how to merge it onto the MUC domain at least

  72. pep.

    (re separate domains I'm specifically thinking about the muc-on-domain-jid-preferrably-subdomain requirement)

  73. singpolyma

    MattJ: woo, then I can just use muc service = space again which is my actual plan either way, haha

  74. MattJ

    So "spaces" would become a feature that can be implemented on a MUC service

  75. Mari0

    Has anybody ever worked on a GDPR compliance xep?

  76. singpolyma

    Mari0: in what way would that be a xep?

  77. pep.

    Mari0, https://wiki.xmpp.org/web/GDPR there's this

  78. ralphm

    What time do we break?

  79. MSavoritias (fae,ve)

    would it be beneficial to have a privacy considerations in xeps? instead of gdpr compliance or something

  80. MattJ

    ralphm, officially in 30min

  81. nicola

    > Has anybody ever worked on a GDPR compliance xep? @Mari0 I started working on it and I proposed yesterday to consider it

    πŸ‘€οΈ 1
  82. Nelson

    https://esl.github.io/MongooseDocs/latest/open-extensions/inbox/

  83. singpolyma

    break into small discussions will be hell to follow remotely

  84. MSavoritias (fae,ve)

    agreed

  85. mathieui

    Nelson, thanks

  86. goffi

    emus: do you know how I can publish a read-only link to the pad?

  87. emus

    goffi: You mean another pad link you have that is locked for edits?

  88. goffi

    yes, to publish on mastodon.

  89. emus

    create that link, in the top right you can set it to locked

  90. goffi

    some people are following updates, and the summaries there are valuable.

  91. emus

    πŸ€” right?

  92. mathieui

    emus, but you can clock on an edit link there

  93. mathieui

    emus, but you can click on an edit link there

  94. emus

    I should lock our pad?

  95. goffi

    I don't see any "locking" option.

  96. mathieui

    goffi, emus is logged in and can do more things

  97. Mari0

    >> Has anybody ever worked on a GDPR compliance xep? > @Mari0 I started working on it and I proposed yesterday to consider it Yes! We talked about it in the past and I think the idea needs to be considered. I think about a GDPR/ privacy (we are Europeans and consider it as a standard) compliance of XMPP by design or by protocol (same thing). Don't know how to implement this but have some ideas I will happy to share with all of you and with Nicola :-)

  98. goffi

    emus: so maybe you could create the read-only link for me and paste it here?

  99. Mari0

    >> Has anybody ever worked on a GDPR compliance xep? > @Mari0 I started working on it and I proposed yesterday to consider it Yes! We talked about it in the past and I think the idea needs to be considered. I think about a GDPR/ privacy (we are Europeans and consider gdpr as a standard) compliance of XMPP by design or by protocol (same thing). Don't know how to implement this but have some ideas I will happy to share with all of you and with Nicola :-)

  100. singpolyma

    AFAICT you can't make a read only link to a publicly editable pad

  101. emus

    https://jabbers.one:5281/file_share/NTShOtZl5aRa_fuy04lxMpYB/zb2rhcPs1EfSGBZXJFjtMhuKPYrQ9D7bSknesxVaJsoHyB4ho.jpg

  102. emus

    https://jabbers.one:5281/file_share/fKkHsN_E_gko-rDyL5GrVjB4/zb2rhcPs1EfSGBZXJFjtMhuKPYrQ9D7bSknesxVaJsoHyB4ho.jpg

  103. emus

    upsbsorry

  104. emus

    I can make it protected and make more people owners

  105. singpolyma

    MattJ: of course then you can exchange the oauth token for a fast token πŸ˜‚

  106. pep.

    Kev, "Resourceprepped to go in resource." what does this mean? hats should be resourceprepped and go in what resource?

  107. singpolyma

    qr code onboarding is interesting, I've always thought of it in terms of push notification since that's what google does but I guess these are equivalent

  108. singpolyma

    fast token in qr code would be new device scans old device, which is backwards

  109. singpolyma

    since passwords are generally zero value 2fa is mostly the main auth and I think push for main auth isn't any worse if done right

  110. MattJ

    Passwords help prevent 2FA spam at this point :)

  111. MSavoritias (fae,ve)

    well we are slowly moving to passwordless anyway (finally) :)

  112. singpolyma

    MattJ: yes, basically. which maybe we can do with throttling etc better

  113. singpolyma

    ELIMINATE PASSWORDS

  114. MSavoritias (fae,ve)

    yes please

  115. mathieui

    talking about mailing lists, who should I bother about getting re-added to members@ after mailman bugged and kicked me out? singpolyma maybe?

  116. singpolyma

    mathieui: you should be able to self-serve if it's just disabled delivery

  117. flow

    came to take a peek at the live stream, but even an documentary about the ordinarly rock lichen seems to be more enteraining right now

  118. MattJ

    flow, enjoy!

  119. flow

    sure :)

  120. flow

    yes please goffi share your screen

  121. singpolyma

    IIRC from the discussion of this reflection it might be a bug in ejabberd since it shouldn't happen if you don't advertise +notify ? But also if it's just your own deployment you can patch ejabberd to change the behaviour

  122. Kev

    There's a line about being able to auto subscribe the owner/publisher to nodes.

  123. singpolyma

    What data from the im observatory is most desired?

  124. mathieui

    Talking about https://observe.jabber.network/

  125. singpolyma

    I think showing the A/B/C rating to users is confusing. but maybe useful for filtering which to show in the first place

  126. MSavoritias (fae,ve)

    agreed. the data shouldnt be available to people imo

  127. mathieui

    MSavoritias (fae,ve), available but not visible by default

  128. MSavoritias (fae,ve)

    yeah that sounds okay too

  129. singpolyma

    really anything less than A is... why are you showing this if you believe in the A rating's validity?

  130. MSavoritias (fae,ve)

    im just thinking showing a list of a servers to a person says nothing

  131. singpolyma

    Right, that too. If I were to consider this I might instead just pick one at random from the list to show them

  132. MSavoritias (fae,ve)

    the choice should have been made before showing anything if thats the aim they are going for

  133. mathieui

    I think e.g. picking from the top at random with a button to show more and another one if you want to pick another

  134. MSavoritias (fae,ve)

    yep

  135. mathieui

    but as emus said, UWPX was an example implementation

  136. singpolyma

    mathieui: yeah, maybe that

  137. MattJ

    mathieui, observe.jabber.network is (confusingly) very different functionality to the old IM Observatory (which did not measure uptime/availability/etc.)

  138. singpolyma

    MattJ: right. I was asking because certwatch is also very different but with some overlap

  139. mathieui

    (I mean, a *real* implementation but only one among the infinite possibilites)

  140. MattJ

    I was confused by your question because jonas also started a project to replace the IM Observatory, and that project is inactive

  141. mathieui

    oh ok

  142. singpolyma

    Something I'd really like to see in providers data: does this provider allow user to receive messages from strangers? (either optionally or by default or whatever) that is, no hardcoded inability to do so

  143. MattJ

    +1

  144. mathieui

    singpolyma, good idea

  145. MattJ

    The option should be [yes, no, configurable]

  146. singpolyma

    this is the #1 thing we have to use for evaluation at JMP because our customers get a lot of messages from strangers usually

  147. Kev

    "This is fine"

  148. emus

    > I think showing the A/B/C rating to users is confusing. but maybe useful for filtering which to show in the first place We host these servers in a spearate list. So the idea is that server maintainers pick the A or B category and expose these to their users

  149. MSavoritias (fae,ve)

    right so uwxp was a bad implementation then

  150. emus

    MSavoritias (fae,ve): I don't think so. rather your impression believes the user shouldn't take any choice. The developer maybe wanted to offer, which is also fine. The same to just shoot the user through the registration automatically to the chat view

  151. emus

    > Something I'd really like to see in providers data: does this provider allow user to receive messages from strangers? (either optionally or by default or whatever) that is, no hardcoded inability to do so noted

  152. MattJ

    singpolyma, there were a few useful aspects of the IM Observatory I think we've lost. One is providing a way to check TLS versions/ciphers supported by a server. It also checked the SASL mechanisms, whether TLS/starttls was enforced. As well as individual servers, it allowed us to get stats on this stuff across the network, which can be very helpful for determining security policies (e.g. "can we advise implementations/deployments to drop TLS 1.0?").

  153. singpolyma

    right, that's fair. It's less clear to me which of these data are useful for the providers list specifically

  154. MattJ

    The old observatory also calculated the SSLLabs rating (A-F), however I don't think we should try to bring that back, as their focus is on the web ecosystem only, and we will want to make our own rules

  155. moparisthebest

    >> @Mari0 I started working on it and I proposed yesterday to consider it > Yes! We talked about it in the past and I think the idea needs to be considered. I think about a GDPR/ privacy (we are Europeans and consider gdpr as a standard) compliance of XMPP by design or by protocol (same thing). Don't know how to implement this but have some ideas I will happy to share with all of you and with Nicola :-) GDPR is a regulation affecting a tiny part of the world, and even then only applies in narrow circumstances, are we going to make a XEP about how to follow every law in every jurisdiction? 🀷

  156. moparisthebest

    It's at most a deployment consideration specific to the server implementation you use, I think

  157. MSavoritias (fae,ve)

    gdpr actually applies almost globally

  158. MSavoritias (fae,ve)

    because it doesnt apply to EU the geographical region

  159. MSavoritias (fae,ve)

    it applies to EU citizens

  160. moparisthebest

    That's incorrect

  161. moparisthebest

    > Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR. https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

  162. pep.

    Well that is if you call "EU" tiny still

  163. ralphm

    moparisthebest, I think that your interpretation is not complete. The GDPR applies to all EU citizens. Targeting here means "involved in". This is why there are numerous US based services that explicitly reject users from IP addresses known to be in the EU, because they cannot determine who is a EU citizen. Also, there are many countries that implement similar legislation, including of course the UK.

  164. singpolyma

    "IM-NG: time for google talk"

  165. moparisthebest

    > Well that is if you call "EU" tiny still pep.: EU citizens appear to be 5.5% of the worldwide population, with multiple single countries having 3x the population, so yes I'd call it tiny

  166. moparisthebest

    ralphm: targeting means targeting, what body in the XSF is qualified to say "yes this complies with this legislation" ? re: "similar legislation" that's exactly my point, why would XSF have anything like a GDPR compliance XEP instead of a "guidelines to minimize private data retention" or something similar?

  167. MSavoritias (fae,ve)

    i agree on that yeah. and i would go further and have a requirment for privacy considerations on each xep

  168. moparisthebest

    GDPR XEP proposal: > Host your own damn server.

  169. moparisthebest

    > i agree on that yeah. and i would go further and have a requirment for privacy considerations on each xep I agree, I think historically this has sometimes been shoehorned into security considerations, and while there is overlap, it's not the same

  170. cal0pteryx

    Sponsoring page: https://xmpp.org/community/sponsorship/

  171. singpolyma

    how is stories different from microblog? mostly just that it can only have one?

  172. singpolyma

    "displayed as a story" sounds like speccing UI

  173. mathieui

    edhelas is talking about https://xmpp.org/extensions/xep-0472.html for stories

  174. edhelas

    https://signal.org/blog/introducing-stories/

  175. mathieui

    singpolyma, that’s a bit of UI but also that influences the type of content produced/metadata

  176. edhelas

    What I was saying is that, basically XMPP wise its really simple to do (just a specific "Profile" in https://xmpp.org/extensions/xep-0472.xml#profiles), its mostly a client side thing to do

  177. singpolyma

    so I guess it's more like avatar than microblog if it's image only

  178. moparisthebest

    "displayed as a story" just means however you decide to display stories in your UI right?

  179. singpolyma

    yes

  180. edhelas

    https://xmpp.org/extensions/attic/xep-0060-1.23.0.html

  181. MattJ

    Maybe like an avatar, but it expires (and most platforms support videos, not just images)

  182. flow

    the xml schema often reveals if something could be extended or not

  183. edhelas

    <field var='pubsub#type' label='Payload semantic type information' type='text-single'> <value>urn:example:e2ee:bundle</value> </field>

  184. singpolyma

    signal seems to support comments on the story and other people can see the comments

  185. singpolyma

    so maybe a pinned, expiring, microblog is basically the flavour. just not usually with text

  186. Kris

    stories could be also combined with location sharing

  187. Kris

    with is often time limited as well and you might want to share where the thing is you are doing

  188. mathieui

    Kris, Pubsub Social Feed has it alread

  189. mathieui

    Kris, Pubsub Social Feed has it already

  190. SavagePeanut

    since we used singnal as an example is encrypted pubsub a thing?

  191. mathieui looks at goffi for encrypted pubsub

  192. Kris

    yes, but I mean the way that Stories are presented in clients, could be combined on how location sharing is done

  193. MattJ

    Kev, goffi, edhelas (and anyone else): Any objections to it being a TTL configured on the node, vs a per-item TTL?

  194. edhelas

    MattJ I think it would be simpler on the UX perspective

  195. Kev

    The TTL is applied per item, but configuring it on the node sounds fine (maybe better) and publish options would be that, I think.

  196. singpolyma

    edhelas: interesting. social feed moves to putting replies in the main feed node? I guess that means allowing public write to your blog but maybe server needs to filter to only replies or such?

  197. edhelas

    MattJ I think it would be simpler on the UX perspective (to have it on the node level)

  198. edhelas

    Having in my client Configuration page: "I want my stories to expire in 1day/2 days/1 week..." and that's about it, but this can also be injected in every items

  199. goffi

    yes encrypted pubsub is a thing: https://xmpp.org/extensions/xep-0473.html and https://xmpp.org/extensions/xep-0477.html (Libervia implements both)

    πŸ‘οΈ 1
  200. MattJ

    From a server perspective it's slightly easier if it's on the node

  201. MattJ

    and slightly easier means "can be implemented sooner"

  202. edhelas

    > From a server perspective it's slightly easier if it's on the node True, and I'd actually present it as it in the Movim UI :)

  203. goffi

    there is also signing: https://xmpp.org/extensions/xep-0475.html and https://xmpp.org/extensions/xep-0476.html (Libervia also implements those)

    πŸ‘οΈ 1
  204. MattJ

    So if there is no strong reason to support mixed TTLs on a node, I'd prefer not to support it

    πŸ‘ 1
  205. goffi

    mathieui ^

  206. mathieui

    SavagePeanut, ^

  207. goffi

    MattJ, per-item TTL seems sensible to me.

  208. Kev

    > So if there is no strong reason to support mixed TTLs on a node, I'd prefer not to support it +1

  209. singpolyma

    Is there a short list of the "problems with MUC" ?

  210. mathieui

    https://xmpp.org/extensions/xep-0405.html I think that’s the one for MIX-PAM

  211. goffi

    FTR PAM is implemented in Libervia Pubsub.

  212. MSavoritias (fae,ve)

    singpolyma, there is https://xmpp.org/extensions/xep-0369.html#reqs from the xep

  213. singpolyma

    even platforms with "explicit joins" mostly do show online/offline for their channels, which is analogous to our in/out. it's just a UI choice

  214. MSavoritias (fae,ve)

    also an interesting thing i have read is that the participants node is seperate

  215. singpolyma

    getting messages from public MUCs while offline for weeks seems like an anti-benefit :P if you really want it all that's what MAM is for

    πŸ‘ 1
  216. MSavoritias (fae,ve)

    also https://xmpp.org/extensions/xep-0369.html#concepts-muc-comparison

  217. MSavoritias (fae,ve)

    yeah agreed. either migrate to mix or clean the muc xep/xeps that it becomes mix

  218. MSavoritias (fae,ve)

    same as we are doing with the rfc

  219. edwinm

    MAMplication.

  220. mathieui

    maybe we could implement a distributed message syncing protocol to solve those issues, I hear there is one that is popular nowadays

  221. singpolyma

    πŸ˜‚

  222. moparisthebest

    > maybe we could implement a distributed message syncing protocol to solve those issues, I hear there is one that is popular nowadays I also hear it's easier if everyone just centralizes on one huge service

  223. Mari0

    > >> @Mari0 I started working on it and I proposed yesterday to consider it > > Yes! We talked about it in the past and I think the idea needs to be considered. I think about a GDPR/ privacy (we are Europeans and consider gdpr as a standard) compliance of XMPP by design or by protocol (same thing). Don't know how to implement this but have some ideas I will happy to share with all of you and with Nicola :-) > GDPR is a regulation affecting a tiny part of the world, and even then only applies in narrow circumstances, are we going to make a XEP about how to follow every law in every jurisdiction? 🀷 GDPR is a standard not only for EU citizens and extra EU citizens located in the Union. The scope o GDPR is to protect uman being integrity not only personal data. e.g. If it's true that you cannot sell parts of your body it's also true you can't sell your data. As you know XMPP is designed to be extensible. So if you are outside the EU you can decide to not use the 'gdpr xep', but a EU citizen or organization i.e. may decide to not interact with servers not implementing it or to give a disclaimer to its users (via their client) that that jid or that muc is on a server that is not GDPR compliant. This may be of interest expecially in mucs where the gdpr data processing rules may be relevant. The starting point of a xep may be the definition of a standard privacy policy. he choice to be gdpr compliant is in the realm of the person or oganization who antains the server, adopting or not adopting the gdpr xep. Sorry for the wall of text

  224. pep.

    > I think historically this has sometimes been shoehorned into security considerations, and while there is overlap, it's not the same I'd also like a Privacy considerations by default in specs

  225. Mari0

    > >> @Mari0 I started working on it and I proposed yesterday to consider it > > Yes! We talked about it in the past and I think the idea needs to be considered. I think about a GDPR/ privacy (we are Europeans and consider gdpr as a standard) compliance of XMPP by design or by protocol (same thing). Don't know how to implement this but have some ideas I will happy to share with all of you and with Nicola :-) > GDPR is a regulation affecting a tiny part of the world, and even then only applies in narrow circumstances, are we going to make a XEP about how to follow every law in every jurisdiction? 🀷 GDPR is a standard not only for EU citizens and extra EU citizens located in the Union. The scope of GDPR is to protect uman being integrity not only personal data. e.g. If it's true that you cannot sell parts of your body it's also true you can't sell your data. As you know XMPP is designed to be extensible. So if you are outside the EU you can decide to not use the 'gdpr xep', but a EU citizen or organization i.e. may decide to not interact with servers not implementing it or to give a disclaimer to its users (via their client) that that jid or that muc is on a server that is not GDPR compliant. This may be of interest expecially in mucs where the gdpr data processing rules may be relevant. The starting point of a xep may be the definition of a standard privacy policy. he choice to be gdpr compliant is in the realm of the person or oganization who antains the server, adopting or not adopting the gdpr xep. Sorry for the wall of text

  226. Mari0

    > > I think historically this has sometimes been shoehorned into security considerations, and while there is overlap, it's not the same > I'd also like a Privacy considerations by default in specs yes, privacy by design this is the point and xmpp for its eXtraordinary nature may be so :-)

  227. moparisthebest

    Mari0: wait are you proposing letting servers advertise whether they are GDPR compliant or not on a protocol level, so that other clients/servers can make decisions based on that?

  228. Mari0

    yes, exactly

  229. MSavoritias (fae,ve)

    but why

  230. mathieui

    did we miss the break

  231. MSavoritias (fae,ve)

    i do agree that it would be nice to have some kind of privacy document that all xmpp development must adhere to.

  232. Mari0

    the entire ecosystem will have benefits

  233. MSavoritias (fae,ve)

    but that wont happen in xsf. and i dont see why it has to be based on gpr

  234. Zash

    https://xmpp.org/extensions/xep-0134.html#privacy

  235. Mari0

    my idea is to introduce the principles of gdpr into an Internet protocol

  236. Mari0

    to protect its users

  237. Mari0

    'cause my friend code is not law :-)

  238. moparisthebest

    > Mari0: wait are you proposing letting servers advertise whether they are GDPR compliant or not on a protocol level, so that other clients/servers can make decisions based on that? Mari0: I'm sorry but this is actually useless, like a button asking the user if their computer has a virus before letting them log into a website (which I've seen in the wild)

  239. moparisthebest

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

  240. Zash

    Lying on the internet??? Who would do such a thingβ€½

  241. moparisthebest

    As protocol authors all we can do is minimize data shared, and clearly specify what is shared, why, and any guarantees or not around it

  242. Mari0

    From the failure to comply with the laws comes responsibility. In EU and everywhere

  243. MSavoritias (fae,ve)

    im confused

  244. MSavoritias (fae,ve)

    is this about laws

  245. MSavoritias (fae,ve)

    or privacy

  246. singpolyma

    boo to new xeps and new numbers :P

  247. Mari0

    it's not bureaucracy

  248. moparisthebest

    > From the failure to comply with the laws comes responsibility. In EU and everywhere Nope, there would be 0 consequences if I ran a server here that advertised GDPR compliance and then did whatever I wanted with the data you sent me

  249. singpolyma

    can we move the gdpr bikeshed :P

  250. pep.

    Somewhat related, someday when I find the energy again I'd probably revive the ToS attempt

  251. singpolyma

    I'm trying to heckle the summit!

  252. Mari0

    I will try to articulate in detail the proposal in the near future in the mailing list also with the help of Nicola and anyone who wants to join

  253. moparisthebest

    The details don't matter, promising compliance with any particular legislation at a protocol level is somewhere between useless and actively harmful

  254. moparisthebest

    Please don't get me wrong, I'm all for security, privacy, data minimization, users being in control of their own data etc, this is just the completely wrong way to tackle it

  255. Mari0

    ok registered your opinion :-)

  256. Mari0

    I'll take in great consideration

  257. pep.

    > promising compliance with any particular legislation at a protocol level is somewhere between useless and actively harmful I disagree. It's about the same as writing down on the web page except it can be used in XMPP clients.

  258. pep.

    > promising compliance with any particular legislation at a protocol level is somewhere between useless and actively harmful I disagree. It's about the same as writing down on the web page except the information can be used in XMPP clients too.

  259. pep.

    > promising compliance with any particular legislation at a protocol level is somewhere between useless and actively harmful I disagree. It's about the same as writing down on a web page except the information can be used in XMPP clients too.

  260. moparisthebest

    pep.: a promise on a website is somewhere between useless and actively harmful as well

  261. pep.

    And yet.

  262. moparisthebest

    You can do everything right, follow every best practice, and still leak data

  263. Mari0

    if the promise in a website or app is not fulfilled it can be serious trouble for those who run it

  264. moparisthebest

    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

  265. moparisthebest

    Therefore the "solution" is to send me the bare minimum, and clearly communicate to users what exactly that is and the risks

  266. pep.

    Can we stop claiming the doom of the world, saying everyone is corrupt and all? You can go all nihilism in your corner of the world if you want, don't bring others down with you

  267. singpolyma

    I wasn't kidding about keeping the room a bit more on topic, guys :P

  268. moparisthebest

    Anything else is somewhere between useless and actively harmful

  269. pep.

    > Therefore the "solution" is to send me the bare minimum, and clearly communicate to users what exactly that is and the risks Yes of course

  270. pep.

    And both aren't incompatible

  271. moparisthebest

    singpolyma: we are discussing XEPs being worked on apparently :P

  272. singpolyma

    yes, but this is the summit room, and they're not talking about it at summit

  273. pep.

    (And how do you communicate this to users? With a spec :o)

  274. moparisthebest

    I thought they were talking about it at the summit?

  275. singpolyma

    no, only in here, heh. summit was a muc/mix bikeshed again

  276. pep.

    not much better :)

  277. Mari0

    singpolyma, is right this is not the place. moparisthebest, your objections are very, seriously even if I disagree ;-)

  278. Mari0

    singpolyma, is right this is not the place. moparisthebest, your objections are valid, seriously even if I disagree ;-)

  279. Kev

    Sorry to run off before the end. currently in the Eurostar departures bunker, which is always a joy. Thanks everyone for another Summit. See you all next year :)

    πŸ‘‹ 1
  280. winfried

    > I will try to articulate in detail the proposal in the near future in the mailing list also with the help of Nicola and anyone who wants to join 1) Several years ago we already started a XMPP GDPR compliance project, 90% finished. With my current knowledge I would definitely do some things differently. 2) This is 100% my expertise (writing data protection impact analysis's for the Dutch national procurement for living). Possibly Nicola is one of the few with matching knowledge... 3) I would be happy help and to help to find the right form.

  281. Kris

    https://xmpp.work/

  282. moparisthebest

    winfried: FYI that discussion moved to xsf@

  283. Guus

    > https://xmpp.work/ Please let me know if you know of job vacancies that can be added there!

  284. emus

    https://jabbers.one:5281/file_share/Ef5mBbPWHUjVyPJkzqEdJubT/zb2rhnJA4FYHXNUvsrBgUzNsZuhiwxGmhxRg9LPXxDz89x6AR.jpg

  285. emus

    found and will bring to fosdem tomorrow

  286. emus

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

  287. FakePeanut

    πŸŽ‰

  288. goffi

    emus: looks like my scarf, I didn't realize at all that it was missing. Thanks a lot!

  289. goffi

    And congrats for the release.

  290. goffi

    Where (and when) are folks going to eat tonight? I'm not sure that I'll move 'cause I need to rehearse my talk and work on a few stuff, but just in case there is something not too far away.

  291. mathieui

    goffi: we're currently in the lounge of the motel one hotel, no decision has been made

  292. emus

    goffi: will bring it tomorrow

  293. emus

    goffi: some are currently at Motel One considering to got for food

  294. goffi

    mathieui: ok. I think that I'll go to a barraque Γ  frites tonight to have time to rehearse my talk, but I may join later.

  295. goffi

    emus: great, thanks!

  296. edhelas

    Back to my hotel :) See you guys tomorrow !

  297. Mari0

    >> I will try to articulate in detail the proposal in the near future in the mailing list also with the help of Nicola and anyone who wants to join > > 1) Several years ago we already started a XMPP GDPR compliance project, 90% finished. With my current knowledge I would definitely do some things differently. > 2) This is 100% my expertise (writing data protection impact analysis's for the Dutch national procurement for living). Possibly Nicola is one of the few with matching knowledge... > 3) I would be happy help and to help to find the right form. Great!

  298. emus

    Mari0: Possibly involve Nicola

  299. Mari0

    > Mari0: Possibly involve Nicola Absolutely. Already is πŸ˜ƒ

  300. emus

    great