XSF Discussion - 2023-02-19

singpolyma: you mentioned somewhere that you support groups in bookmarks (similar to how roster item groups work). I assume the element is just called group. But what's the namespace?

jcbrand, I think something isn’t right with the tos and froms in the 425 examples

i think the intent is that the room fakes a retract coming from the person who originally send the bad message?

Yeah that could be coming from the participant. Also, as someone made me realize, the room doesn't exactly need to get involved here. Optionally to remove the message from the archive, but otherwise clients can check that a user has the proper affiliation for this.

Though.. I guess that wouldn't go well with fine grained permissions (hats etc.)

I think it's better if the room does that. Otherwise you have to implement two verification methods in the client. And developers tend to fuck up just one

Well you don't trust (client) developers but you trust (server) developers, which is it :p

I get that it's not exactly trust, fwiw, this was a bit of a pun. But I'm not sure I understand why "two" checks in the client (that would have also been implemented on the server anyway?)

> i think the intent is that the room fakes a retract coming from the person who originally send the bad message? Why would it do that? The retraction is from a moderator.

The MUC service determines whether a retraction by a 3rd party (i.e. moderator) is allowed

to be compatible with retractions?

i’m not saying we should be compatible with retractions. but i thought that was the goal

Yeah I think it's a worthy goal, but somehow I think it's misleading to pretend that the author retracted their own message

and you'd still know who moderated it because of the 'by'

true

yeah I guess it's better how you suggest due to compatibility concerns

yes i'm on the fence if we should make it compatible with clients that only support retractions

because

I implemented both together and kinda always saw them as related

> I think it's misleading to pretend that the author retracted their own message ✏

> I think it's misleading to pretend that the author retracted their own message Yes and also, the message is really from the room, not from the author

then you can’t be compatible with retractions

One could argue that if a client only supports XEP-0424, it doesn't support XEP-0425

I like the idea of allowing them to somehow still retract messages without knowing about XEP-0425, but not necessarily at the expense of semantics

Yeah. Also could this be abused?

Normal users can't send stanzas on behalf of other users

If we have to fake from who it comes from?

So not really, as long as the client checks the sender

Unless you don't trust the MUC service at all, but then why are you using it?

Yeah the MUC is supposed to check that you're who you say you are in a payload so no. ✏

Ok

Daniel: I'm a bit on the fence. I can see someone making the argument: "The `from` is from the sender because it's their original message that's retracted and the `<moderated>` element specifies who did it". But then again, clients that don't check the moderator element might then wrongly report that the user retracted their own message

yes I don’t think they necessarily need to be compatible

The way I had it before, with the `moderated` outside of the `retracted` element had the advantage that you could put other elements instead of `retracted` inside it, like `correction` (or whatever it's called). I guess you could put the `moderated` inside the `correction`, but I think I prefer the old way. I swopped them out to get compatibility with XEP-0424, but if we don't have compatibility anyway due to the `from`, then I'm not sure the new way is better. ✏

I guess with this way, it might be easier to add support for XEP-0425 if you already support XEP-0424

Since I'm a web dev who doesn't use an XML parser, I think I have a bit of a blind spot as to how other client devs do things.

a client that has support for retractions can easily add support for moderation even if the syntax and verfication (check it's coming from bare) is slightly different

the hard part isn’t the xml parsing

one could maybe even argue that a client might want to support retractions but not moderation

yes

Or that a client that supports retractions and then also unwittingly supports moderation is dangerous

I still think there's a general moderation use-case, that goes beyond retractions also

But people didn't like that I alluded to it without providing details

wurstsalat, is there a short description of what's supposed to go in what category now?

What's a "Tool" for example ✏

(That isn't also a client, or a component, or..)

Daniel: group, same namespace as in roster, put inside the bookmarks2 extensions area

singpolyma: OK thanks.

pep.: There isn't yet. Shouldn't be too hard though, since you can apply more that one category

(and there are examples of tools)

Ah? That section is empty for me

you probably selected a specific platform

oh, good call

If it's not too hard, maybe add some kind of "X items hidden by filters [Clear filters]"

good idea

I'm bringing a question re 377 here, I couldn't find a difference between spam and abuse. Any clue? I also suspect they'd be different from one community to the other..

Spam =mass messages selling you stuff. Abuse =personal. Insults etc

Maybe

From an operator perspective it's interesting because you can feed 'spam' into your other spam detection heuristics and abuse probably will require some sort of manual intervention

Personally, they all fall into abuse. One thing I'd be tempted to say for spam is the repeated characteristic. But I've also often heard the word abuse used for this

hmm

I think spam is always abuse, but abuse isn't always spam

Yes ✏

spamming gore pics or advertisements is spam

but like, belittling a certain person is abuse, but not spam

> Unsolicited bulk electronic messages says https://en.wiktionary.org/wiki/spam#Noun ✏

Did you want the message? Did they send it to lots of recipients (like, in MUC)? Yes to both = spam!

Yes to first, no to second → abuse, maybe.

To me Spam is mostly automated. Last night wasn't automated

No true spam isn't automated :)

Just highly processed

I can see this isn't very clear. Unsolicited can me many things as well. Most of my mailbox is unsolicited mail

And that's after I've sorted spam out

I wonder if it would be possible for a server/community not to include one or the other term from 377 in clients :/

Without forking said clients

Do we still have a good reason to disallow editing older messages? While updating my code to support moderation last night I'm pretty sure I also allow retraction and edit of any message now

(since moderation needed that)

Fwiw Conversations 3 will allow you to edit any message

So no I don't think so

Sounds like a vote for me to allow it now then if I will after I rebase on c3 anyway ;)

The big difference to me is that C3 will show full history of edits

That will be nice

Which I think gets rid of some of the side effects of allowing to edit a message from five years ago

Excellent!

IIRC that's a recommendation in the XEP too, to show history of edits.

I also prefer A(ny)MC

Yes. But tell that early twenties me to design the database properly

:)

wurstsalat, how about adding GET query params support to be able to share links from that doap page

In MUC, clients cannot inject <status/> I can imagine ?

> Yes. But tell that early twenties me to design the database properly Movim had this flaw as well, now I keep the whole history and replace the messages once generating the bubble (might be able to show the history actually as well) ↺

On a totally different topic, would it be possible for servers to serve avatars over HTTP ?

It's already possible in the XEP, and we have HTTP features already such as for HTTP upload.

This could greatly help to reduce the congestion in XML streams

By moving off to HTTP. Are you also going to seel your unborn child?

Wat

Is this actually an issue you have?

sell*

Well, it's more an improvement

edhelas: you can of course, but there are privacy concerns since you leak IP to with over http

When connecting to big chatrooms, I could easily fire parallel Curl download and not get each avatar in base64

Can you do both? I think you can, then clients can choose

singpolyma yes, the Avatar XEP can do that :)

what we could do is replace XEP-0153 with something like blurhash, like a 4x4 png

Zash as well :)

IIRC larma or someone pointed out that a tiny PNG bit without header and stuff would be more efficient than blurhash

We're using blurhash already for media thumbnails

(we, Cheogram and Cheogram Android)

singpolyma ther's a XEP for that ?

edhelas: just using sims

<thumbnail with a data uri

> wurstsalat, how about adding GET query params support to be able to share links from that doap page Using hugo?

javascript :(

Well there's an obvious graceful fallback which is you can only share the page and not the query

You can do a lot with CSS actually, but probably not all of the settings

#client #server etc could work tho

It seems like DOAP,s <xmpp:note/> doesn't accept structured markup? (does it have to be explicitely defined?) Where do people describe their support for monsters like 0045 or 0060?

plain text

Is CDATA valid in XMPP ?

Should be? It's just syntactic

Ok

Because we agree that <body>> quoted message</body> is not valid ?

Correct

So cdata or entity

They're equivalent

Perfect 👍

&gt; that is, not &amp;gt; :P

Right

> &gt; that is, not &amp;gt; Why would that not be valid?

I mean &amp;gt; isn't ">"

That's what movim was sending before the last commit, displaying &gt; everywhere in fallback messages instead of >

Ah.

I just wanted to mention that only & and < are not allowed in XML character data, but > is. > though must actually be escaped as &gt; when in CDATA if it appears after ]] ✏

Pretty sure many XML parsers are totally fine with `<a>></a>`