XSF Discussion - 2023-08-09

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

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

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)

> "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. ↺

> 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 ↺

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

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

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

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

very good post that I very much agree with.

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

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

yeah. hard read but worth it

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)

Why not both?

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

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

yep. xsf culture pretty much

> 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? ↺

I think you can have a bit of both

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

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

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

Original link, haven't clicked second yet

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

> 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

"Community", not "server"

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

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

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

I guess it's maybe not identical

it gets fuzzy with Mastodon yeah

Mastodon and most other Fediverse implementations

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

In XMPP or Activitypub

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

Funny how we're immediately talking about protocols :)

Le eternal bias of protocol devs? :/

Of course

> 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

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

at least not how I read that post I linked

It's always a best-effort

jonas’, me neither, fwiw ✏

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 🤣

If not then I actually agree with it too :)

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

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.

My reading too

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

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.

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.

> 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 ? ↺

> "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 ↺

> 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

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.

MSavoritias fae.ve: agree

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

that is an admin hat responsibility

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

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

When right now they are not and we could do more

XSF is a community, arguably

and there are many communities using xmpp

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

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

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

right, fair

i meant xsf too but yeah.

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

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

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

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.

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

singpolyma, what constitutes an abuse though

That's what the post tries to detail

pep.: that is of course up to the community

And the point also is to be explicit about it

and differs by the norms and values of the community

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

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

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.

(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)

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

Yeah I agree with jonas’

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

MSavoritias fae.ve, I disagree with that wording.

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

more like *implicity* allowed then?

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). ✏

TIL .ve is a TLD

jonas’, one often implies the other though..

> 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

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

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 ✏

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 ✏

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.

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)

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

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

I don't know where the problem is?

> 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...). ↺

Can we "outcast" someone server wise in XMPP ?

same for those really

sure

mod_firewall can do all sorts of things

the technical how is not the question ✏

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

There's a XEP for that ?

edhelas, even pubsub has an outcast affiliation

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

Yes but one by one

Here I'm talking about a whole service/server

edhelas: this is about community management

a server is rarely the scope of a community

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

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

MSavoritias fae.ve: block "them" what?

the server.

blocking servers != blocking on the server level

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

and in XEP-0191 on the individual level

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 ✏

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

Why not?

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

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

qy: no, of course not

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

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

Have we?

singpolyma, why "of course not"?

could we maybe first define the "defederation nonsense"?

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

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

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

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

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

i think its still applicable especially on the operators room

but on xsf as a whole of course

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.

Please no more heated discussions in the operators channel 😅

(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)

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

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

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

Daniel, yeah

> no, changing the password kicks existing occupants Til

no, changing the password effectively bans existing members ✏

Oh right

jonas’, wait, does it?

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

you need to present the password when joining

It certainly doesn't automatically puts them as members

yes

And yeah you need the password to join again

wording, sorry

but that's the difference to unbounded tokens ✏

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). ✏

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

does not hurt

pep., I suggest to require expiry by default

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

any number less than infinity is good

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

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

Hm, OTP for MUC?

> 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...

>> 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...

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.

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

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

"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

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

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.

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

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.

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

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?

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

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

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

cheogram is an xmpp client?

Cheogram Android is yes

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

(i also don't have ios)

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

prerelease is the status on google play?

oh, cool!

fdroid channel i understand.

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

so the xeps are voted on?

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

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

what about emotions?

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

You need http_file_share

Is emotions something different then 👍🤔?

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

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

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

lol

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

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

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

I took it from context to mean custom emoji