XSF Discussion - 2024-02-28

  1. jonas’

    so I'm thinking about what'd be needed or sensible for a Pronouns XEP. I.e. a way for people to announce their preferred pronouns into a conversation. I was thinking to make it part of presence, which has the upside that it immediately (without extra code) propagates to all peers (including MUC). It also has the downside that: - It needs to be configured per client - There is no way to control propagation of that information to untrusted MUCs. I lack knowledge of the needs of the primary users of such a feature and I wonder whether anyone can close that gap?

  2. jonas’

    an alternative implementation would use a PEP node (or maybe vcard), which do not need support by all (emitting) clients (only one), but doesn't as easliy propagate to MUCs.

  3. jonas’

    (but has the advantage of fine-grained ACLs if necessary)

  4. pep.

    It has been discussed a times here already iirc, well vcard support rather.

  5. pep.

    But yeah rich presence may be better dire propagation :/

  6. pep.

    But yeah rich presence may be better for propagation :/

  7. jonas’

    vcard has the downside that you can't ACL different fields differently.

  8. jonas’

    A user might not want to expose their real name to a MUC, but exactly because of that they may want to transport she/her as pronouns.

  9. pep.

    Maybe the best move is to make this possible? :/

  10. pep.

    Or have different vcards for different mucs

  11. pep.

    MEP when

  12. jonas’

    pep., I don't think that making sub-parts of a complex XML structure in PEP (or vcard-temp even) ACL-able is a thing which is likely to happen.

  13. pep.


  14. pep.

    MEP though.. :p

  15. jonas’

    what's MEP again?

  16. pep.


  17. jonas’

    is that for users to write to?

  18. pep.

    Basically make it possible to publish stuff on the MUC's node

  19. pep.

    I guess?

  20. jonas’

    I thought this was more of a thing for MUCs to use to broadcast stuff

  21. jonas’

    not for users of MUCs to have MUCs broadcast stuff on their behalf

  22. pep.

    I guess it could be both

  23. pep.

    Some nodes could be writable

  24. jonas’

    and then publish an item per user...?

  25. pep.

    That would also allow for different avatars, omemo keys

  26. pep.


  27. jonas’


  28. jonas’

    that needs a well-written spec on top of MEP even

  29. jonas’

    to ensure that stale data is deleted when a user is (permanently) removed from a room.

  30. jonas’

    and to prevent that users can write over each other's data in the same node

  31. pep.


  32. jonas’

    in the end, a huge effort. while I can see the use, I'd like to not block on that.

  33. jonas’

    the question is whether *always* exposing pronouns to a semi-anon MUC is a problem or not. I truly cannot judge that.

  34. Daniel

    given the overhead of PEP I would rather not create a pep node for every indivdual field of vcard

  35. pep.

    jonas’: "it depends"?

  36. jonas’

    pep., that means "yes"

  37. jonas’

    because the question contained "always" :)

  38. jonas’

    s/yes/yes it is a problem/

  39. pep.

    not sure if that was implicit here, but then there's no corollary to me saying that it's always true for non-anon rooms

  40. pep.

    not sure if that was implicit here, but then there's no corollary to me saying that it's always false for non-anon rooms

  41. MSavoritias fae.ve

    i would like pronouns to have permissions

  42. MSavoritias fae.ve

    because it depends when you want to expose them yeah. like specific group chats may not be reseptive. or maybe you have a anti-trans uncle or something

  43. MSavoritias fae.ve

    > vcard has the downside that you can't ACL different fields differently. that seems like a *major* downside to vcard. is that current vcard?

  44. MSavoritias fae.ve

    > vcard has the downside that you can't ACL different fields differently. that seems like a *major* downside to vcard. is that for current vcard?

  45. jonas’

    yes, unless someone knows more than me on that.

  46. lovetox

    sorry i wouldnt say thats a "downside"

  47. lovetox

    seems excessive to me to have every possible filed have ACL

  48. jonas’

    lovetox, what other solutions are there?

  49. lovetox

    none probably we have currently

  50. jonas’

    do you have any better idea?

  51. lovetox

    but does anyone know a service or example where this is provided?

  52. MSavoritias fae.ve

    isnt that vcard supposed to have your nickname, picture and rest of the profile stuff

  53. lovetox

    my idea is to not do it because of cost/benefit ratio

  54. MSavoritias fae.ve

    not having acl there seems like a complete miss

  55. pep.

    MSavoritias fae.ve, yes and no

  56. lovetox

    we have acl MSavoritias fae.ve

  57. lovetox

    you can decide on a per jid basis, who can see your VCard

  58. lovetox

    what you asked is, on a per JID / per field bases

  59. lovetox

    what you asked is, on a per JID / per field basis

  60. MSavoritias fae.ve

    > you can decide on a per jid basis, who can see your VCard well that seems still bad imo

  61. lovetox

    i know some social network can set on a per field bases permissions, but also only to whole groups like, facebook "friends", not a per user basis

  62. MSavoritias fae.ve

    if vcard is supposed to hold your profile and you cant restrict said profile

  63. lovetox

    im not saying that it couldnt be useful to someone out there, obviously i cant judge that, my opinion is, that its huge technical task, for very very small amount of users

  64. lovetox

    MSavoritias fae.ve, i just wrote that you can restrict your profile on a per jid basis

  65. MSavoritias fae.ve

    your *whole* profile

  66. MSavoritias fae.ve


  67. lovetox

    yes, thats what you call a profile

  68. lovetox

    what you mean is "field"

  69. MSavoritias fae.ve

    yeah seeing here https://xmpp.org/extensions/xep-0292.html#self-pep-retrieval the profile has basically anything

  70. MSavoritias fae.ve

    like even address

  71. lovetox

    only if you set it

  72. lovetox

    dont know what you are getting at, facebook has also a huge profile with everything, no sane user fills it out

  73. MSavoritias fae.ve

    well of course you cant set it because xmpp doesnt care about safety or privacy here

  74. MSavoritias fae.ve

    anyway. i already have some ideas. this just shows that vcard should use that framework too

  75. jonas’

    which ideas? :)

  76. lovetox

    while your at it, also show how a UX looks like where you configure that all

  77. jonas’

    I mean setting permissions to "groups" would IMO suffice, and there's precedent for that. XEP-0060 does allow specifying access by roster group membership, for instance.

  78. jonas’

    but we need some other, non-static groups, such as "non-anon MUCs", "semi-anon MUCs", "that specific entity"

  79. pep.

    profiles per-groups

  80. pep.

    per-groups profiles

  81. pep.

    Maybe rather than per-field ACLs

  82. Daniel

    vcard with acl per field def. sounds better than one pep node per field

  83. jonas’

    separate vcards could be easier on the protocol level and clients could expose it the other way around to make management easier.

  84. pep.


  85. pep.

    Clients can get around it UI-wise. We can propose suggestions

  86. MattJ

    I think I also lean towards having fully separate vcards at the protocol level

  87. jonas’

    then the question becomes how you configure routing of the vcard request IQ to the correct endpoint on the server-side.

  88. MattJ

    The vcard4 IQ? :P

  89. jonas’

    that, yes.

  90. Zash

    The vcard rewuest iq was removed, it's just pubsub now

  91. jonas’

    by correct endpoint I mean "the correct vcard for the requesting entity"

  92. Zash

    The vcard request iq was removed, it's just pubsub now

  93. MattJ

    Zash: yes, we'd need to add it back 🙂

  94. jonas’

    or can you set ACLs on items?

  95. Zash

    S i g h

  96. pep.

    Isn't pubsub just fine?

  97. MattJ

    jonas’: you can't

  98. pep.

    I'm not sure I get it

  99. jonas’

    then we indeed have a problme.

  100. jonas’

    then we indeed have a problem.

  101. pep.

    A server knows if someone is in the requestee's roster no?

  102. pep.

    If we just care about rosters

  103. jonas’

    pep., yes

  104. MattJ

    pep.: and the requesting entity just looks at both nodes or whichever it thinks it ought to see?

  105. jonas’


  106. MattJ

    Public vs private

  107. jonas’


  108. jonas’

    I don't think two is enough.

  109. MattJ

    How many do you want?

  110. jonas’

    I'd expect N nodes.

  111. pep.

    Sorry I'm lost

  112. pep.

    Yeah N

  113. jonas’

    pep., user requests vcard as pubsub retrieval to a fixed, well-known node. The server needs to decide which of the many vcards to return. Pubsub does not support that.

  114. MattJ

    Does anyone have an example UI for that? 🙂

  115. MattJ

    I'm all for privacy, but too much complexity for the user can seriously harm it

  116. pep.

    MattJ, well you don't need to make it overly complex UI-wise, but you can allow for configuration

  117. jonas’

    MattJ, yes. visibility settings like "Only mutual contacts", "Mutual contacts + private group chats", "Mutual contacts + all group chats", "Everyone", on every field. The client then composes the vcards and publishes them with the matching ACLs.

  118. jonas’

    potentially even "Mutual contacts in group X"

  119. MattJ


  120. MSavoritias fae.ve

    that sounds basically like google + circles :P

  121. jonas’


  122. pep.

    jonas’, fwiw I'm not sure I want a "private group chats" / "public channels" dichotomy like you said above for this too. (especially not paired with mutual contacts). But I guess we can review peer groups one we sort out the how

  123. jonas’


  124. pep.

    (Think family private groupchat where I haven't said anything yet)

  125. jonas’

    MattJ, I think even snikket has three levels already, doesn't it?

  126. MattJ


  127. lovetox

    maybe lets start by sorting out trivial things like mentions first :D

  128. pep.

    That's another problem

  129. pep.

    That can be solved in parallel :)

  130. jonas’

    Mentions involve text, I like to stay out of those after the Big Markup Flamewar. Too much fire and burnout in that.

  131. pep.


  132. jonas’

    MattJ, similarly to how snikket restricts the options there, I think clients would generally do that, too. The protocol level benefits from some simple flexibility though, IMO.

  133. MattJ

    I agree, but we've also seen time and again that overly generic/complex protocols don't get implemented

  134. MattJ

    or that they get implemented the way XEP-0016 was implemented

  135. jonas’

    hence "simple flexibility" :)

  136. jonas’


  137. MattJ

    Many people around today probably don't remember XEP-0016 UIs

  138. MattJ

    But it's a good example of how protocol can lead to terrible UIs

  139. MattJ

    I can't remember which client started the trend of "let's just make a simple 'block' feature on top of XEP-0016", but it was good

  140. jonas’


  141. MattJ

    But hard to pull off reliably without a simpler protocol that matched those semantics, hence XEP-0191

  142. MattJ

    Then we had that translation logic on the server side for a while, but that also wasn't super reliable

  143. jonas’


  144. jonas’

    the obvious translation of the UI I suggested to protocol would be to indeed split the fields into different nodes and apply ACLs

  145. lovetox

    max i would do is, public/privat

  146. jonas’

    but then you end up splitting vcard4 into a flock of pubsub nodes which does, indeed, cause overhead.

  147. MattJ

    You said we need N versions of the profile earlier, but is N really unbounded?

  148. MattJ

    Can we not manage it with 2 versions, with appropriate access controls on each?

  149. pep.

    I'd argue that no, it's gonna be meh, but I'd be willing to see where that leads to

  150. jonas’

    MattJ, can we make an escape hatch for >2?

  151. jonas’

    if so, I'm game.

  152. MattJ

    I guess what I'm gettin at is: do we need to present different info to different entities, or only control the visibility?

  153. MattJ

    If we present different info, how many different kinds of info?

  154. jonas’

    different info would be good

  155. MattJ

    Because I think that's what determines how many nodes we need

  156. jonas’

    I'd like to consolidate MUCs on a single JID

  157. jonas’

    but I can't because avatar.

  158. MattJ

    Reminder that I'm in the "JID per persona" camp, so that influences my thinking on this

  159. MattJ

    Avatar being particularly relevant

  160. jonas’


  161. jonas’

    please fix my poezio then

  162. jonas’

    to support >1 account.

  163. MattJ

    tmux :)

  164. pep.


  165. jonas’


  166. pep.

    jonas’, I wish

  167. pep.

    But that will likely never happen

  168. pep.

    And yeah no I'm also tired of "use a different account" tbh

  169. MattJ

    But then how long will it take for poezio to get a profile editor UI that supports everything you want here?

  170. jonas’

    MattJ, I don't need to, I can use another client to set up the profile.

  171. pep.

    I alrady have ~7 accounts and it's a pain to manage. Plus yeah not all clients supporting it

  172. pep.

    I already have ~7 accounts and it's a pain to manage. Plus yeah not all clients supporting it

  173. MattJ

    Well we need better support for multi-account in clients, not spend the next 10 years trying to get everyone to build a sane flexible profile editor

  174. MattJ

    Which will invariably lead to unintentional leaks

  175. jonas’

    MattJ, okay, I can buy into that.

  176. jonas’

    different JIDs does have a significant advantage.

  177. pep.

    I don't know.. I still think there's value in providing some kind of provacy

  178. jonas’

    fixes a bunch of stuff at once.

  179. pep.

    I don't know.. I still think there's value in providing some kind of privacy

  180. MattJ

    pep., so do I

  181. jonas’

    and then two levels may actually be sufficient-ish.

  182. pep.

    That doesn't rely on having to create different accounts

  183. MSavoritias fae.ve

    you people have different accounts? :P

  184. MattJ

    Why not?

  185. MattJ

    MSavoritias fae.ve, I do

  186. jonas’

    MSavoritias fae.ve, at least four, I think.

  187. jonas’

    probably five

  188. MSavoritias fae.ve

    im too in the camp of one account with permissions btw

  189. jonas’

    depends on whether you count my notafrankensnikket

  190. MattJ

    In some cases you don't even want the two correlated by their actual address

  191. MattJ

    And you can't sanely fix that with protocols

  192. MSavoritias fae.ve points at gnunet :D

  193. MattJ

    XMPP is not that though

  194. MSavoritias fae.ve

    it can use gns to do that. but its ot to current discussion

  195. MattJ

    and gnunet is not XMPP, similarly

  196. MattJ

    Account isolation is built into XMPP, it's a feature we have and should build upon

  197. pep.

    Someone still needs to fix omemo and vcard-te^Wwait..

  198. MSavoritias fae.ve

    its mls now :P

  199. pep.

    Same issue

  200. pep.

    We'll need to fetch keys somewhere

  201. pep.

    MEP when

  202. Zash

    Do we have basic message delivery reliability yet?

  203. MattJ

    Zash, where've you been? :)

  204. MSavoritias fae.ve

    wair we dont

  205. MSavoritias fae.ve


  206. jonas’

    Zash, if not omemo, yes.

  207. Zash

    MattJ, in the world where only Prosody does s2s-XEP-0198 ?

  208. MattJ


  209. jonas’

    we've reached a reliability quote where people are not complaining anymore.

  210. Zash

    The world where I can't see what my mom writes because of omemo, on some devices

  211. pep.

    I still have issues with gajim that I need to debug at some point re omemo.. (not being able to read messages when gajim isn't online)

  212. pep.

    (which is.. ?!?)

  213. MSavoritias fae.ve

    so more arguments for me to implement OX i guess :/

  214. pep.

    I'm not entirely sure the encryption mechanism is responsible here..

  215. jonas’

    very likely it's at least related. per-device keys + forward secrecy add a lot of moving parts and sources for issues.

  216. MSavoritias fae.ve

    yeah that is my thinking too. plus with nomadic identities forward secrecy seems unworkable

  217. pep.

    Yeah but it feels like another MUC/MIX thing when someone mentions something wrong with OMEMO and that OX is then the obvious solution

  218. pep.

    Not that I don't want OX mind. For different reasons, in different contexts

  219. MattJ

    We need OXEMO

  220. Zash


  221. MattJ


  222. pep.

    Probably. just like we need MIC, or MUX

  223. MSavoritias fae.ve

    why not OMEXO

  224. pep.

    I've also heard re OMEMO that we need OX because handling keys with OMEMO is hard and having one key makes it easier, but nothing says OX should have only a single key, it's just that a bunch of devs got together and said "yeah ok let's do it this way"

  225. pep.

    It can also be done with OMEMO and has been discussed many times already

  226. MattJ

    and given that OMEMO is widespread already, I think that approach has some merit

  227. MSavoritias fae.ve

    the problem personally is that my usecase is: > The account a person has is completely portable and independent from the device/app that it is used with and is backed up so that it can be recovered using social trust.

  228. MSavoritias fae.ve

    and > This library has an account that is basically a "hub" that collects all the other subaccounts. This way a person can have a gaming account, family account, friends account and so on. > This needs more thought on how it will work. and specifically safe enough so each profile can't be linked to the other one or to the account. or that knowledge of the main doesn't disclose the profiles. > The account with all the profiles can be exported and imported on the fly. it can also be only portable mode where the apps keep no information after the person "logs out". This would be the default for untrusted devices. > The export also holds all the messages and media and everything. can be granular.

  229. pep.

    MattJ, indeed

  230. MSavoritias fae.ve

    i bet its going to be difficult to make omemo work here. to my understanding at least

  231. Schimon

    ping to singpolyma

  232. Schimon

    Good day to one and all

  233. Schimon

    What do you think of form caching? The forms to cache that I think of are those to input data into.

  234. Schimon

    Suppose I have a contact for bookmark managing (i.e. bot). 1) I am generally offline. 2) I find a URL address I want to add. 3) I open the list of ad-hoc commands and fill the form to add a new bookmark. 4) Once online again, the forms, one by one, will be sent to the bot.

  235. Schimon

    Link Mauve, what do you think?

  236. MSavoritias fae.ve

    https://daniel-lange.com/archives/186-Opencollective-shutting-down.html fyi

  237. Schimon

    Link Mauve, what do you think of form caching?

  238. MattJ

    I'm not certain given the lack of context, but it may be related to https://www.opencollective.foundation/ rather than https://opencollective.com/

  239. MSavoritias fae.ve

    the post links to the second opencollective blog directly in the beginning https://blog.opencollective.com/

  240. MattJ

    Yeah, I suspect the author may be confused (as it is indeed confusing)

  241. MattJ

    They probably have a project hosted by OCF

  242. MSavoritias fae.ve

    the email they give also points the second opencollective. hmm

  243. Zash

    > OCF was created by Open Collective Inc. (OCI) such confuse

  244. MSavoritias fae.ve

    lets wait for an official announcement

  245. MattJ

    Shutdowns like that are so frustrating. What were they doing for it to become suddenly unsustainable?

  246. MSavoritias fae.ve

    i remember reading opencollective wanting to become a DAO in a blockchain

  247. MSavoritias fae.ve

    (the second collective)

  248. MSavoritias fae.ve

    but idk what happened with that

  249. MattJ

    and they take 8% of project funds? https://www.opencollective.foundation/#pricing

  250. jonas’

    > We responded to increased demand arising from the COVID-19 pandemic without taking the time to establish the appropriate systems and infrastructure to sustain that growth. > > Unfortunately, over the past year, we have learned that Open Collective Foundation's business model is not sustainable with the number of complex services we have offered and the fees we pay to the Open Collective Inc. tech platform.

  251. MattJ

    The XSF doesn't pay any fees to OCI (because the XSF doesn't take any % from projects)

  252. MattJ

    and if they can't sustain the complex services, can't they just retire those, whatever they are?

  253. MattJ

    Rather than throw hundreds of projects into disarray?

  254. MattJ


  255. MSavoritias fae.ve

    what are the alternatives now? besides liberapay

  256. MattJ

    The likely news here is that OCF, not OCI, is shutting down, so there are many other fiscal hosts (including the XSF, for XMPP projects) to choose from

  257. MSavoritias fae.ve

    ah so the collective that manages the payments shut down. oh well

  258. MattJ

    I don't think you even need a fiscal host to use OCI if you manage your own bank account and accounting

  259. MattJ

    (which is equivalent to Liberapay)

  260. MSavoritias fae.ve

    the thing is i cant take donations in finland

  261. MSavoritias fae.ve

    its illegal

  262. MattJ

    OCF was a generic fiscal host that you could use, if you couldn't find another (so if you're not an XMPP project, you can't use the XSF, but the OCF allowed more general projects)

  263. MSavoritias fae.ve

    but probably that is not solved with a fiscal host. not sure

  264. MattJ

    Not sure either, sorry

  265. MSavoritias fae.ve

    no worries. i do have an xmpp project i would like to make fiscal host at some point tho

  266. MSavoritias fae.ve

    if i can work it out. hence me asking

  267. MSavoritias fae.ve

    ah found a better source https://opencollective.com/opensource/updates/regarding-the-announcement-to-dissolve-open-collective-foundation you are right its the fiscal host. > You may be aware of recent developments regarding the dissolution of Open Collective Foundation (OCF) by the end of the year 2024.

  268. MSavoritias fae.ve

    reading through https://xmpp.org/community/fiscalhost/ how many of these are hard requirments?

  269. MSavoritias fae.ve

    like i do have a chatroom and its an open license and open source

  270. MSavoritias fae.ve

    but i dont have an "active community". like multiple commiters or an issue tracker

  271. MSavoritias fae.ve

    so what are exactly the roadblockers here? or is this the wrong venue for this?

  272. MattJ

    This is the right venue

  273. MattJ

    The criteria in the first list are not necessarily blockers, as it says, exceptions can be made. The main purpose is to ensure the projects we host are "real" XMPP projects, rather than someone just publishing a 5-line Python script that uses slixmpp so they can apply ;)

  274. MSavoritias fae.ve

    probably its a bit early still. espesially since the finnish thing takes 5-7 months apparently to be approved. but i am interested to know what to "prepare". Im talking about: https://git.sr.ht/~msavoritias/Guile_XMPP https://git.sr.ht/~msavoritias/Applesauce and xmpp:guile_xmpp@conference.magicbroccoli.de?join

  275. MSavoritias fae.ve

    > The criteria in the first list are not necessarily blockers, as it says, exceptions can be made. The main purpose is to ensure the projects we host are "real" XMPP projects, rather than someone just publishing a 5-line Python script that uses slixmpp so they can apply ;) ah mine has like a couple of dozen pages of docs but no code yet. but hopefull soonish

  276. MattJ

    The XSF has to make declarations about its income and outgoings, and we need to ensure those stay true

  277. MSavoritias fae.ve

    ok? what was that a reply to

  278. MattJ

    So it's not that a 5-line Python script would certainly not qualify, but as there is some overhead and risk involved, we can't take on just anyone

  279. MSavoritias fae.ve

    ah fair. thats why i asking how to make this "legimate"

  280. MattJ

    Tick as many of the boxes as you can, apply, and it will get discussed... we'll find out

  281. MSavoritias fae.ve

    ok. i will apply for the finnish thing and try to write some code until then. hopefull i have issues enabled by then :P

  282. MattJ

    And at least you'll get some feedback if you're not accepted, so you can perhaps try again later if it's nothing major

  283. MSavoritias fae.ve

    sounds good

  284. Guus

    Google keeps insisting that 'mam muc' is some kind of query for an Asian squid fish sauce. The personalized search result cake remains a lie.

  285. edhelas

    The XSF should spend its budget on boosting those keyword the correct way.