jdev - 2023-01-11

https://xmpp.org/extensions/xep-0060.html#publisher-publish-error-forbidden Any clue what "insufficient privileges" mean in this context? Can a publisher of the node have insufficient privileges?

if you're no publisher, yes

But as a publisher?

Can one edit/delete other publisher's items for example? Is there such restrictions available?

what's the actual question?

a client always needs to be prepared to handle authorization errors

Trying to see what's currently available for moderation on pubsub

depends on the implementation.

services can do whatever they like

(as long as they return the appropriate responses)

That's always a great answer in a standard :P

'60 is quite flexible in that regard

Ok, maybe there's some way for servers to advertize capabilities in this regard, so that clients don't need to do trial and error and can avoid providing UI when the feature isn't there or stuff like that

Products vs protocols and all that. The XEP defines a protocol, there are many ways to use it. There is nothing specifically written anywhere about moderation in pubsub, but that doesn't mean it's not possible, and it might be a good idea to write it.

I'm planning to have a look at that in the "near future"

pep., I think this is a prime example for a case where the error response should contain a more refined description of its cause

flow, maybe. I do think (as I said above) that a client should be able to know beforehand it's not authorized to

Of course there can be both

pep., agreed though.

There's assorted places in XMPP where you can't tell if something will succeed until you try, and it's ... not great.

it would be good if you could disco#info a node and get a list of all _your_ permissions on _that_ node ✏

maybe, I am not sold on that

Kev, yeah.. I've seen the last thread on the list about reactions :P

that appears to be a case where it is better to ask for forgiveness than permission

flow, disagree

flow, tell the user that

that's terrible for UIs

^

fair point

nice for machine-to-machine, but not good for human interfaces.

"Thanks for writing out your thesis. I'm afraid you're not allowed to submit it."

I wonder if we should design a generic protocol pattern where an operation can be marked as "dry-run" (or "don't do it"). so you can check if you would be allowed to do it

flow, but then you'd need the content of that operation to be available first?

flow, trying all possible optinos in a UI when showing it is very inefficient

pep., the content does not matter if it is a dry run

it may

ok, depends on what you classify as content then

flow, banned words, length limitations, ... there are lots of ways even real content may matter

but also parameters like which item ID you are retracting

well the item ID could by the correct one

and for the other parameters you mentioned: those are probably also not discoverable otherwise

They could be made available via disco

you probably can't take everything into consideration, there is a certain tradeoff

Well a spec is a living document right? :P

Surely at some point you'll have an error, and that's where indeed good description of the error is necessary

(and i18n)

I think i18n is secondary to the refined description (but sure can't hurt)

As it's likely to be shown straight to the user, I think it's absolutely necessary

flow, ... how is it secondary?

that ^

Now of course between what one feels is necessary and implementations progress, there's always a gap

I believe such refined descriptions cause typically more confusion in case of the average user

as in non-tech safy

even more important then to know ahead of time whether a thing is allowed

right

I wasn't considering the human UI aspect in this discussion (for some reason)

about MAM: do clients actually implement support for <fin stable='false'>, eg, by re-fetching MAM periodically until stable='false' disappear? cf paragraph just above https://xmpp.org/extensions/xep-0313.html#sect-idm46316171986560

"they should"

I suspect they don't :)

It's quite a lot to ask of a client

it's probably hard to get a proper UX around that indeed

Typo in the paragraph btw: "it the server could return best-guess results", "it"

(or I don't understand the sentence)

it's quite tricky for slidge to guarantee stable MAM results for legacy networks that allow message editing (and re(tr)actions…) but I guess always replying to queries with stable=false would be very very very ugly anyway. fastening collation would help a lot, but I hope to figure something out before (if?) it's worked out :(

Always replying with stable=false is the right thing to do, though, if the results aren't stable.

The universe is unstable

do not look up false vacuum decay unless you need more existential angst

(speaking of "universe is unstable")

I would be more cautious: _our perception of_ the universe is unstable ;)

Just serve clients stable results, and if they change... just tell them it's only their perception that is unstable

But all this to say, more seriously, that I think some pragmatism is required

sounds like a plan to me! you hated my bug reports already? hold on, it's about to get worse :P

If you serve results and say they are stable, and they later change, the client may not update them. You might or might not care about that.

Lots of clients don't have to care about this stuff, because they fetch on demand, but anyone who wants to do a full-MAM-sync client and wants to support clustered servers that can operate in a split mode have to care.

We have the same problem with Matrix bridges

Since the history can change at any time

> Lots of clients [citation needed]

Ok. Some clients.

It's different to a clustered XMPP instance knowing that the past N entries in the archive haven't been fully replicated and confirmed

In such a setup, both client and server using the 'stable' flag correctly can still achieve consistent synchronized history

Right, but even in a situation where no queries are ever stable, it's useful to flag that to a client, isn't it?

So that the client knows it can't use a "sync once, and then just catch up" strategy.

Yes, I would agree that if the server judges that clients should not cache the results, it should always set stable=false

Would the server flag a full response btw, or would it only flag parts of it? If it knows only a subset is unstable

agreed about pragmatism. I should just ignore reactions/edits/retractions of old messages, and be happy with only "live updates". guaranteeing proper ~infinite history sounds like a lot of trouble for something that most likely won't matter. the reason I want to implement MAM is just to make groups usable on mobile…

But I can then understand that clients might just ignore that flag

> But I can then understand that clients might just ignore that flag Sure, clients can do what they like based on the properties they want.

What's not going to happen in most clients, is implementing two different sync strategies, and choosing between them on a per-query basis

Sure.

>Would the server flag a full response btw pep. full response, since it's in <fin> I think?

A client that does the "right" thing, paired with a server that always returns stable=false would be somewhat problematic

I'm happy enough that clients choose to ignore the edge cases if they want to. As long as we give them the information to do the right thing if they so choose.

It almost suggests we need a third flag

> A client that does the "right" thing, paired with a server that always returns stable=false would be somewhat problematic Not necessarily. Doing the right thing with stable=false only means not treating it as a source of truth, which means refetching it next time you want that segment of the archive.

"temporarily unstable" (try again in a bit) or "permanently unstable" (do whatever you want)

Permanently unstable is probably a property of the whole archive that could be advertised.

isn't there some overlap between what "permanently unstable" entails and what the fastening collation xep tries to do?

Is there?

"Unstable" means that there may be messages missing from the middle of your results.

And the fastening collation is a way to indicate on results that later stanzas have been applied to change somewhat-meta-data.

from my (very narrow) point of view, there is some overlap: I can't say stable="true" because of this msg metadata changes

But you can.

nicoco, it's another message, not a message that has changed

Or, at least, the collation stuff shouldn't affect it. All that should affect stable/not is whether messages might be missing from the returned sequence.

>another message, not a message that has changed indeed. every "metadata event" (edits, reactions, ...) is indeed a new message stanza in XMPP. that does not map to what most networks do where the MAM-equivalent returns collated results only.

And that's fine.

And that's what collations allow XMPP to act like.

>whether messages might be missing from the returned sequence the overlap is here? if a MAM server serves collated results, it's because they don't want to serve all "metadata edit events" but only the current state (probably as optimization for storage and network IO)

Well, no, I don't think that's true.

If your MAM archive serves fastenings as normal messages, they're in sequence. If it doesn't, they're always missing. ✏

I think unstable-ness is completely orthogonal to serving of collations.

(While accepting I could be wrong)

> If your MAM archive serves fastenings as normal messages, they're in sequence. If it doesn't, they're always missing. I'm having trouble parsing this. Could you expand a little? 🤯️

I'm saying that your MAM archive will either serve up messages that are a fastening, or will not serve up messages that are a fastening. Whichever way it chooses to do, which messages are returning a particular period (stable=true/false) is unaffected by subsequent fastenings being processed by the archiving server.

s/returning/returned for/

> The third form, "collate", presents each traditional IM message, as "simplified", but within the result includes summary information about the fastenings (and pseudo-fastenings) encountered. what I meant by overlap was: if a server serves "summary information about the fastenings", clients should always treat it as "stable=false". or doesn't that make sense?

I mean that by nature, the "summary information" is unstable (like the universe)

I think I understand your point, but I don't agree with it entirely.

If you want to render that message again, you'll want to refetch the collation, yes. But you do at least know that the message itself is there, that no new messages have been inserted before it, etc. You can render a page from your local cache, for example, and fill in the fastenings as they come in from a subsequent query.

Kev: I understand. from a client's perspective it is different in this regards. Thanks for the replies. "Not all stanzas are born equal" could be the subtitle of the fastening collation spec.

Or "It seemed like a good idea at the time", which applies to much of XMPP :)

Retractions with <body/> included are really not user-friendly.. "This person is retracting a message that they may have not wanted you to see, so we're going to repeat it", or "This person has retracted a message that was taking quite some space, so we're going to repeat it because it's good that you can see it once more"

That's really all this makes me think about :/

Hey there, I'm having a fuzzy memory of someone mentioning ad-hoc commands being implemented by some fork of Conversations, does that ring a bell, and would anyone know which client that might be?

rom1dep, Cheogram

Conversations fork, has ad-hoc commands

Sounds like it might be it, thanks a lot MattJ 🙂

https://cheogram.com/

pep.: about retractions, would you rather see no message at all for clients that don't support it?

I wonder. I think yes. Maybe at the most "The user retracted a message", to say they did something, but without context it's probably useless so..