XSF Discussion - 2023-08-09


  1. moparisthebest

    Sweet thanks Kev I'll put it on my to-do list

  2. pep.

    "edhelas> [..] in the end only the nickname is sent on the wire" (re references) < I thought we did occupant-id fwiw

  3. pep.

    fwiw, re mentions, I've had on my TODO to write something saying "we've done this, but I'm not planning to do anymore work on it. Feel free to take over" (seems like edhelas wants the feature enough though to carry it for a while? :p)

  4. edhelas

    > "edhelas&gt; [..] in the end only the nickname is sent on the wire" (re references) &lt; I thought we did occupant-id fwiw Yes occupant-id, but the body will have the same look as the current messages, so no "@" or else.

  5. edhelas

    > fwiw, re mentions, I've had on my TODO to write something saying "we've done this, but I'm not planning to do anymore work on it. Feel free to take over" (seems like edhelas wants the feature enough though to carry it for a while? :p) I think my PR + https://bouah.net/specs/mentions.html is already a good base to work on, some more review and work need to be done to stabilize things and fix all the quirk but it's already something that I'm close to be able to work with in my own client

  6. pep.

    > Yes occupant-id, but the body will have the same look as the current messages, so no "@" or else. Sure

  7. pep.

    You still have that "&gt" bug btw :p

  8. pep.

    https://share.bouah.net/lX9NlKKEu0CEHm_sh7rlYic-/l3SvGPCSTFySdlXwR6MfSA.jpg

    🙄 1
  9. jonas’

    https://oliphant.social/@welshpixie/110856038828950795

  10. MSavoritias fae.ve

    very good post that I very much agree with.

  11. Ge0rG

    There was a preceding blog post that I can't find currently by her regarding toxic masto admins

  12. Ge0rG

    ah, it's at https://dotart.blog/welshpixie/the-toxic-manosphere-of-fedi

  13. MSavoritias fae.ve

    yeah. hard read but worth it

  14. moparisthebest

    Hard disagree, end users should have the tools to provide their own safety, protection, and well-being. In fact they should ideally be running their own servers (note: this isn't saying anyone including server admins shouldn't block hateful people, but expecting daddy server admin to ensure you never see anything bad is the realm of silos like apple/Google/Twitter/Facebook etc etc)

  15. MattJ

    Why not both?

  16. Ge0rG

    wait, we are in xsf@, is it even on-topic?

  17. MattJ

    I assume the intended topic was community building/management/protection, and that's pretty relevant to the XSF

  18. MSavoritias fae.ve

    yep. xsf culture pretty much

  19. moparisthebest

    > Why not both? I'm not sure they are compatible, you can't say "here's what you need to protect yourself" *and* "your server admin will 100% protect you" can you?

  20. moparisthebest

    I think you can have a bit of both

  21. MSavoritias fae.ve

    i dont think the point of the article is about selfhost or not

  22. MattJ

    moparisthebest, are you referring to the original link? I didn't read it as being about server admins

  23. pep.

    jonas’, thanks for the link. I also agree very much :)

  24. moparisthebest

    Original link, haven't clicked second yet

  25. Ge0rG

    moparisthebest: my stance as a server admin is that it's much easier if only one person (the admin) does the work than if everybody has to do it, but there are subtle differences between xmpp and masto in that regard

  26. moparisthebest

    > if you choose to run a community, you are responsible for the safety, protection, and well-being of the people in that community This part

  27. MattJ

    "Community", not "server"

  28. pep.

    "You" can also choose to run a community not by yourself, fwiw

  29. pep.

    "You" can also choose to run a community not only by yourself, fwiw

  30. moparisthebest

    Hmm I read "community" and "server" as the same there...

  31. MattJ

    I guess on Mastodon the two might overlap a lot, but I don't think that's the relevance to the XSF - XMPP has a community that spans many servers

  32. moparisthebest

    I guess it's maybe not identical

  33. Zash

    it gets fuzzy with Mastodon yeah

  34. MattJ

    Mastodon and most other Fediverse implementations

  35. moparisthebest

    And there's no one person or body "running" the community across multiple servers

  36. moparisthebest

    In XMPP or Activitypub

  37. pep.

    No but say a MUC room's CoC / MUC service's CoC can be managed collectively. Or maybe if that ever happens, Spaces

  38. MattJ

    Funny how we're immediately talking about protocols :)

  39. pep.

    Le eternal bias of protocol devs? :/

  40. MattJ

    Of course

  41. moparisthebest

    > if you choose to run a community, you are responsible for the safety, protection, and well-being of the people in that community Regardless of definitions, I think my main objection to this is it's not possible on an open federated network, only in a silo Mods can *react* , but implying you can pre-emptivly stop all harmful things from reaching the community is just incorrect, I don't like making promises that can't be kept

  42. jonas’

    moparisthebest, that you have to preemptively stop everything is not what they're saying.

  43. jonas’

    at least not how I read that post I linked

  44. pep.

    It's always a best-effort

  45. pep.

    Me neither, fwiw

  46. pep.

    jonas’, me neither, fwiw

  47. moparisthebest

    That's how I read it, join and admin will protect you, you don't need to be responsible for your own safety, you can toggle "automatically download and display images from strangers" in your client no problem 🤣

  48. moparisthebest

    If not then I actually agree with it too :)

  49. moparisthebest

    Maybe simply setting expectations is the important thing, I feel like people who come from silos have quite different ones than we are used to

  50. jonas’

    no, what I get from that post: - the community leadership must make a clear stance what is acceptable what is not - the community leadership must enforce that - and the community leadership must decide whom they want in their community and whom they don't; there is no way to have a community for truly everyone.

  51. MattJ

    My reading too

  52. Daniel

    In general I like the idea of preventing anyone who inherited more than let's say 100k from replying to my mastodon posts. I just wonder about the practicality

  53. MSavoritias fae.ve

    yep. and by community leadership it can be xsf or the mods in the room or what is acceptable to be hosted in the server.

  54. pep.

    moparisthebest, the ideas you express here are harmful to a community that isn't full of privileged people IMO. Not that I'm surprised anyway.

  55. edhelas

    > In general I like the idea of preventing anyone who inherited more than let's say 100k from replying to my mastodon posts. I just wonder about the practicality Maybe ask to submit your Tax declaration when creating an account ?

  56. TheCoffeMaker

    > "Community", not "server" this ... sorry to interrupt, but this is true ... a server can hold many communities and, is in this way an admin responsibility to lead the hosted communities? I don't think so ...but besides that ... lowering the toxicity on a community is very subjective, I agree with the article abt all the topics BUT in which hat we should put the responsibility is matter of where and how toxicity arise .. for example, my XMPP instance hosts a few communities, if anything happens and I get bothered I delegate the responsibility to community's admin/lead

  57. moparisthebest

    > moparisthebest, the ideas you express here are harmful to a community that isn't full of privileged people IMO. Not that I'm surprised anyway. pep.: Absolutely not, and I think it's ridiculous you think this

  58. moparisthebest

    Please, point to anything I said or even implied that is harmful to anyone

  59. MSavoritias fae.ve

    TheCoffeMaker: Not lead but if you see a group chat that is created to organize doxxing for example it is up to you to shut it down. Or if you have a user that spams.

  60. TheCoffeMaker

    MSavoritias fae.ve: agree

  61. MSavoritias fae.ve

    You should have rules in your server on what kind of topics you want to host. I think thats the point at least.

  62. TheCoffeMaker

    that is an admin hat responsibility

  63. MSavoritias fae.ve

    I do think that the xmpp community should make community rules like that more clear.

  64. singpolyma

    Not sure what you mean by "xmpp community". xmpp is not a community

  65. MSavoritias fae.ve

    When right now they are not and we could do more

  66. singpolyma

    XSF is a community, arguably

  67. singpolyma

    and there are many communities using xmpp

  68. TheCoffeMaker

    > Not sure what you mean by "xmpp community". xmpp is not a community this is also true

  69. jonas’

    when people *here* say the XMPP community, I think we can safely assume the XSF to be meant.

  70. Zash

    I'd think it a little wider than the XSF (members?) itself, but yieah

  71. jonas’

    right, fair

  72. MSavoritias fae.ve

    i meant xsf too but yeah.

  73. singpolyma

    I completely agree with the post about community leadership, and I don't think anyone really disagrees with the core of what it is saying. Basically says "community leaders should do their job". Which of course is true. Even moparisthebest who runs some very lax communities will ban abuse because of course he will

  74. jonas’

    but the XSF is at the core somewhat, being gatekeeper for the official stamp on the protocol extensions.

  75. Zash

    Relevant: https://xkcd.com/1095/

  76. MSavoritias fae.ve

    to put it to something practical: Operators room is hosted in xsf. and lets say that we have a admin and they are hosting transphobic or racist group chats on their server. and they have been warned. should we allow them to still be part of the operators room if they dont want to do anything about it? Im putting this as an open question not as a suggested action here. for example activitypub safe communities like .art above would say absolutely we should.

  77. MSavoritias fae.ve

    and i think these are the kind of questions that can be raised here

  78. pep.

    singpolyma, what constitutes an abuse though

  79. pep.

    That's what the post tries to detail

  80. singpolyma

    pep.: that is of course up to the community

  81. pep.

    And the point also is to be explicit about it

  82. singpolyma

    and differs by the norms and values of the community

  83. singpolyma

    MSavoritias fae.ve: I guess it depends what the point of the operators room is. If they aren't being transphobic or other such in the operators room itself, and if they are present there to get support in their technical operations, and if the purpose of the operators room is for operators to support each other in that way, then probably having them in the room is sensible. But I'm not in that room nor do I have a clear view of its purpose, so this is a hypothetical statement on my part

  84. Zash

    So the question is: Are you allowed to be an asshole somewhere else?

  85. jonas’

    singpolyma, I'd like to go on on that hypothetical. Having a known transphobic and active in a community, even if they don't *show* that there, still may deter trans people from participating for all kinds of reasons.

  86. jonas’

    (one reason I can come up with: often you may share your domain name which may easily resolve into PII, which you may not want to share with someone who denies you the right to be who you are)

  87. MSavoritias fae.ve

    exactly what jonas' said. it shows what kind of behavior is allowed in that community. and may deter people from participating.

  88. pep.

    Yeah I agree with jonas’

  89. Zash

    operators@ is archived in public with infinite retention ...

  90. jonas’

    MSavoritias fae.ve, I disagree with that wording.

  91. pep.

    That's a bit harder to assess though if the observed behavior is outside of said community

  92. jonas’

    MSavoritias fae.ve, because the scenario we're in is where that behaviour *inside* the community would not be allowed. this is regulating worldviews, not behaviour.

  93. MSavoritias fae.ve

    more like *implicity* allowed then?

  94. jonas’

    MSavoritias fae.ve, because the scenario we're in is where that behaviour *inside* the community would not be allowed. this is regulating worldviews, not behaviour (inside the community).

  95. qy

    TIL .ve is a TLD

  96. pep.

    jonas’, one often implies the other though..

  97. singpolyma

    > So the question is: Are you allowed to be an asshole somewhere else? yes, exactly this. since everyone is some kind of unacceptable in some place. But I guess I can see there may be some kind of line at while "known spokesperson for transphobia" for example is unwelcome no matter what they say even in some generic spaces

  98. jonas’

    pep., it often does, but not always within a given community.

  99. pep.

    Personally I'd be happy to have a community be over-protective of their people and do a preventive ban or sth. Knowing that it's still possible for the affected person to try and reach admins/the moderation team

  100. pep.

    Personally I'd be happy for a community be over-protective of their people and do a preventive ban or sth. Knowing that it's still possible for the affected person to try and reach admins/the moderation team

  101. pep.

    Personally I'd be happy for a community to be over-protective of their people and do a preventive ban or sth. Knowing that it's still possible for the affected person to try and reach admins/the moderation team

  102. jonas’

    singpolyma, and another aspect of that hypothetical is that even just trans-allies may be uncomfortable sharing advice in the room if they're uncomfortable with making the life easier for known transphobics.

  103. edhelas

    How can this work for a federated network ? There is also the issue with "declared ban" VS "silent ban" (basically you know that you are blocked on this server VS you never know if your content is actually handled by the other server)

  104. jonas’

    edhelas, you learn about something or someone, you mark them as outcast in the MUC, done.

  105. pep.

    I'm not sure what's the issue with federation really. Why does it matter?

  106. jonas’

    I don't know where the problem is?

  107. edhelas

    > edhelas, you learn about something or someone, you mark them as outcast in the MUC, done. There's MUC, and there's MUCs/Pubsub nodes (for Movim etc...).

  108. edhelas

    Can we "outcast" someone server wise in XMPP ?

  109. jonas’

    same for those really

  110. jonas’

    sure

  111. jonas’

    mod_firewall can do all sorts of things

  112. jonas’

    the technical how is not a questino

  113. jonas’

    the technical how is not the question

  114. jonas’

    if we cannot do it technically, this is the best place to fix that

  115. edhelas

    There's a XEP for that ?

  116. jonas’

    edhelas, even pubsub has an outcast affiliation

  117. jonas’

    https://xmpp.org/extensions/xep-0060.html#affiliations

  118. edhelas

    Yes but one by one

  119. edhelas

    Here I'm talking about a whole service/server

  120. singpolyma

    edhelas: this is about community management

  121. singpolyma

    a server is rarely the scope of a community

  122. singpolyma

    usually a MUC, or a cluster of MUCs, or similar

  123. MSavoritias fae.ve

    If a server chooses to allow certain types of group chats on their server i would still like to block them

  124. singpolyma

    MSavoritias fae.ve: block "them" what?

  125. MSavoritias fae.ve

    the server.

  126. jonas’

    blocking servers != blocking on the server level

  127. jonas’

    blocking servers is supported by at least prosody in MUC (just add the domain to outcasts), for instance.

  128. jonas’

    and in XEP-0191 on the individual level

  129. singpolyma

    I fail to see what blocking a server you aren't talking do accomplishes, but sure if you really want to you can of course

  130. singpolyma

    I fail to see what blocking a server you aren't talking to accomplishes, but sure if you really want to you can of course

  131. qy

    Oh jesus christ we're not planning on bringing the activitypub defederation nonsense here are we

  132. pep.

    Why not?

  133. MSavoritias fae.ve

    i say we can do better than the activitypub current way of doing things

  134. MSavoritias fae.ve

    but yes choosing who you communicate with is a big part of that

  135. singpolyma

    qy: no, of course not

  136. qy

    "You were meant to destroy the walled gardens, not join them!"

  137. singpolyma

    Anyway, we've veered far off topic I think at this point

  138. pep.

    Have we?

  139. pep.

    singpolyma, why "of course not"?

  140. jonas’

    could we maybe first define the "defederation nonsense"?

  141. jonas’

    because I don't know what that even is supposed to mean

  142. singpolyma

    > Have we? Yes, if the topic is XSF related than what people want to do on their private servers isn't really the point

  143. jonas’

    and I anticipate a heated discussion to start and I'd rather not have this end badly because of ambiguous wording

  144. singpolyma

    I'd rather we stop the discussion before it gets heated, since it's not productive :)

  145. MSavoritias fae.ve

    > could we maybe first define the "defederation nonsense"? blocking servers because they dont comply with CoC or server culture

  146. MSavoritias fae.ve

    i think its still applicable especially on the operators room

  147. MSavoritias fae.ve

    but on xsf as a whole of course

  148. jonas’

    singpolyma, this isn't off-topic, for two reasons: (a) as the XMPP protocol, to my knowledge, does not have support (beyond maybe ad-hoc commands) for admins to block stuff on their entire domain, this is easily a valid protocol discussion ("enumerating use cases"); (b) this spun off of a discussion around XSF/xmpp community moderation policies, in the context of which this is certainly discussable.

  149. MattJ

    Please no more heated discussions in the operators channel 😅

  150. jonas’

    (for instance, it would be useful for us XSF mods to have a control to ban people across the entire muc.xmpp.org domain, without having to resort to -rtbl-add in a certain secret place)

  151. singpolyma

    jonas’: sure, if we want to discuss XSF community policy that is of course on topic and important, especially since we are working on finalizing the CoC work for XSF

  152. pep.

    singpolyma, well it's also useful to have an idea of use-cases so that the protocol can be improved as jonas’ just said. Not just what concerns the XSF

  153. Daniel

    pep.: Re https://bouah.net/specs/muc-token-invite.html Wouldn't an unlimited token just be a password?

  154. pep.

    Daniel, yeah

  155. jonas’

    no, changing the password kicks existing occupants

  156. Daniel

    > no, changing the password kicks existing occupants Til

  157. jonas’

    no, changing the password effectively bans existing members

  158. pep.

    Oh right

  159. pep.

    jonas’, wait, does it?

  160. jonas’

    (it doesn't *kick*, but it prevents them from ever rejoining, i.e. ban without kick)

  161. jonas’

    you need to present the password when joining

  162. pep.

    It certainly doesn't automatically puts them as members

  163. jonas’

    yes

  164. pep.

    And yeah you need the password to join again

  165. jonas’

    wording, sorry

  166. jonas’

    but that's the difference to tokens

  167. jonas’

    but that's the difference to unbounded tokens

  168. jonas’

    a password-protected MUC requires knowledge of the current password at join-time. a muc-token-invite flow requires knowledge of the token at affiliation-grant time (i.e.: once).

  169. jonas’

    a password-protected MUC requires knowledge of the current password at join-time (i.e. always unless you run an always-connected shell client). a muc-token-invite flow requires knowledge of the token at affiliation-grant time (i.e.: once).

  170. pep.

    Should I add wording like this somewhere to make it easier to understand?

  171. jonas’

    does not hurt

  172. jonas’

    pep., I suggest to require expiry by default

  173. jonas’

    i.e. unless the user explicitly requests anything else, expire after 24h or so

  174. jonas’

    any number less than infinity is good

  175. jonas’

    (well, I'd personally say any number less than a week is probably good)

  176. pep.

    Yeah I guess. I added that in security considerations but it's probably best as a requirement

  177. Zash

    Hm, OTP for MUC?

  178. moparisthebest

    > Even moparisthebest who runs some very lax communities will ban abuse because of course he will Yea this has grown pretty awkward actually, this is someone else's muc with someone else's rules who made me admin for timezone reasons, it's valuable to keep because it feeds the rtbl during times of attack, but if it were up to me I'd ban quite a few more people in there...

  179. moparisthebest

    >> moparisthebest, the ideas you express here are harmful to a community that isn't full of privileged people IMO. Not that I'm surprised anyway. > pep.: Absolutely not, and I think it's ridiculous you think this > Please, point to anything I said or even implied that is harmful to anyone Still bothers me pep. thinks and says stuff like this but won't point to anything concrete, anyway...

  180. pep.

    I guess you're just too much free speech and libertarian @# to me and I've already spent plenty of energy trying to explain stuff over the past few months. And I'm tired of it.

  181. MattJ

    Okay, I'm aware of history, but no need to drag up into this conversation if we can just discuss what's at hand

  182. moparisthebest

    If you won't explain that's fine but then don't say I'm anti-non-priveleged people in a public muc, because I 100% disagree with that and I feel it's a huge misunderstanding

  183. pep.

    "If you won't explain that's fine" yay putting the load on the other person, over and over. Anyway I'll stop answering you and I'll let others burn themselves if they want

  184. moparisthebest

    Right if you are going to accuse someone of something in public then normally you'd be expected to explain, anyway I'm done too I've stated my objections

  185. emus

    We passed 3000 follower on Fosstodon! 🎉️ That means we not just got about 2300 new follower since 2020, we also exceeded our X (Twitter) account.

  186. emus

    https://fosstodon.org/@xmpp/110861536077654922 https://twitter.com/xmpp/status/1689372627935055872

  187. inky

    i don't understand why, but my friends are telling me they don't like using jabber because they need two things - a) - emotions, and b) - stickers. i don't use anything else so i never used emotions.

  188. inky

    and i don't understand use case for stickers too.

  189. inky

    but still, what do you know about the stages of these two? are there xeps already? i know about stickers, i guess there is a xep proposal, and it needs to be voted about?

  190. inky

    what about emotions? is there a xep? when people vote for it?

  191. inky

    so that after that server and client devs will start to develop?

  192. singpolyma

    I just shipped prototypes of both in cheogram Android pre-release today

  193. inky

    cheogram is an xmpp client?

  194. singpolyma

    Cheogram Android is yes

  195. inky

    how to get prereleases? (i don't even have android right now, i may have in the future, but i can tell my friends)

  196. inky

    (i also don't have ios)

  197. singpolyma

    There is an fdroid channel for pre releases from https://cheogram.com

  198. inky

    prerelease is the status on google play?

  199. inky

    oh, cool!

  200. inky

    fdroid channel i understand.

  201. singpolyma

    Google Play has a beta channel also, but it gets new stuff a bit slower because of review

  202. inky

    so the xeps are voted on?

  203. singpolyma

    There are a lot of different xeps that one can use for there features, but I'm using only published versions yes

  204. singpolyma

    There are a lot of different xeps that one can use for these features, but I'm using only published versions yes

  205. inky

    for stickers support, the server also has to support storing sticker packs right?

  206. inky

    what about emotions?

  207. inky

    are there plugins for prosody i need to install, so that my friends could use these features with my server?

  208. Menel

    You need http_file_share

  209. Menel

    Is emotions something different then 👍🤔?

  210. pep.

    emotions aren't very well transmited over the wire :)

  211. Menel

    That's only possible in the "Matrix" ? 🤔

  212. Menel

    .... I'll show myself out...

  213. agh

    lol

  214. singpolyma

    > for stickers support, the server also has to support storing sticker packs right? No

  215. singpolyma

    > Is emotions something different then 👍🤔? Well, what I've specifically got the prototype for is *custom* emoji beyond what is defined by Unicode

  216. moparisthebest

    What are emotions? Is that slack-style custom emoji reactions or?

  217. singpolyma

    I took it from context to mean custom emoji