XSF Discussion - 2019-08-02

Hi, I am new here, I would like to suggest an idea, I'm thinking about collaborative editor in XMPP for some reasons We have some stuff already in XMPP could use for it:   • XHTML-IM ( https://xmpp.org/extensions/xep-0071.html )   • XMPP E2E Security ( https://wiki.xmpp.org/web/XMPP_E2E_Security )   • Publish-Subscribe ( https://xmpp.org/extensions/xep-0060.html )   • Bookmarks ( https://xmpp.org/extensions/xep-0048.html )   • Multi-User Chat ( https://xmpp.org/extensions/xep-0045.html )   • and maybe other XEPs I didn't learned yet!
 What do we need:   • Shows cursors and selections of remote users   • Show the others having joined the session and something like Chat State Notifications ( https://xmpp.org/extensions/xep-0085.html ) and Chat Markers ( https://xmpp.org/extensions/xep-0333.html ) XEPs   • Syntax highlighting   • That's all I have for now

Maybe the idea is old or something I don't know, I'm just telling my thoughts!

There's https://xmpp.org/extensions/xep-0284.html

well, looks good, I will try with it

pep., Ge0rG does that proposal for adding a feature under a feature break entity caps?

Yup. And probably the schema to.

I still think it's less wrong than putting all combination os sub-features into individual feature var strings.

except that it breaks all the things

create a new feature tag that's recursive

And caps3

caps3.11

caps for workgroups

'390 is still experimental

so that’s the least of worries

Is ecaps2 implemented at all in clients? I know it's in xmpp-parsers, and I know there's a prosody module to convert to escaps2, but that's about it?

could it not be named, "pubsub:order-by" ?

lovetox, that's the second proposal

But it's ugly

why though? it breaks nothing

pep., aioxmpp has an implementation, obviously

and nobody looks everyday at xml streams, so i dont really care if its ugly

lovetox, yeah as I said in the mail

I was mostly curious if there were prettier alternatives

Or smarter ones

jonas’, right

XEP-0128 forms!!kk

actually...

yeah that was my next bet

actually..

you have to disco info the pubsub service itself anyway

so it can announce all features inside its extended form

like httpupload does

with max-size etc

or pubsub nodes, or .. muc? :)

its still bit of a hack

Well, forms are for config. I think the way we would have done this is per-subprotocol features. It is a bit untortunate. Nested features would not work correctly with CAPS.

Then you can do disco#items on muc with order-by and rsm, imagine the possibilities!!1!

nested features would break any schema-validating parser

although I’d like to get written down somewhere that unknown elements and attributes MUST be ignored, unless they carry an attribute {urn:xmpp}critical="true" :>

in which case you have to run in circles screaming full of terror

One other possibility is querying a node that is the 'main' subprotocol namespace and adding the rsm feature on that

ralphm, but the roundtrips

Oh right, disco and nodes.

(and it doesn’t work with caps either)

I didn't say is was pretty

i would just add a field var=feature to the extended form

and list all features there

prettier in my opinion

ralphm, also, what if I create a pubsub node named like a feature (very common in PEP)

jonas’, hush

Yeah

jonas’: obviously, this must be forbidden by the protocol!

Wasn't there some overlaps like this already?

I think for now just having a new pubsub feature and a new disco feature suffices

If there only a handful of combinations, we don't have to overengineer

Should we also update pubsub to create pubsub#with-rsm btw? To fix the current thing that's broken

"broken"

Yes

That was my suggestion

yeah pubsub has already endless feautres, just add pubsub#rsm and be done with

Backwards compatible, too

Old clients will see the rsm feature and will try

I'm curious though who mandates to add RSM in disco

RSM itself?

Not really

Rsm for disco isn't defined

Not that

Or at least not explicitly

disco#items?

ralphm, you misunderstood

What says currently, "if you do rsm with pubsub, add rsm in disco#info"

Because I'd want to remove that when introducing pubsub#rsm

Nothing?

Maybe instead, if you want RSM on disco items, we need to expose a feature, and update XEP-0030

update XEP-0030 !!1! /me runs wavings arms in the air

Am I going to get punished for daring to update a Final XEP?

Or a new XEP

:(

pep., the elders will come down from the temple and whack ye upon thy fingers

Zash: like who?

Dunno

https://xmpp.org/extensions/xep-0059.html#support how can I, without breaking it, say "don't do it anymore" :)

heh, there are mentions already of the issue in this paragraph

Maybe that could have been sorted out at this time

few years ago jabber.ru was supporting XEP MUC-Filter which is not exist on xmpp.org and it was working very well with Isida-bot ( http://isida.dsy.name/wiki/en:Index ) and added later to other bots I have unofficial mod_muc with muc-filter support, working on ejabberd-2.1.13 and previous versions the module was not published by Ejabberd, I think it was monopolized by jabber.ru, I know many who wanted to get it but when they asked about it, the answers is like something that did not exist There is short description about the XEP here ( https://github.com/xnamed/isida4/wiki/muc-filter#principle-of-operation ) A list of bot filters that it can do here ( https://github.com/xnamed/isida4/wiki/muc-filter#configuring-the-bot ) If anyone is interested about that, if the description not enough I will send the module if necessary, I can explain it if you don't know erlang and I think it could be implemented the same way on Prosody One of the good things about this feature, users can choose filters in each room, no need to write filters for the server for everything For some time I thought there is no need for it, but there are still some kids, It was very annoying to me when one of my friends room got spammed, more than 1000 messages, then I get them all on my other devices because of XEP MAM :)

xnamed: I'd be happy to add that to Openfire

I'm happy to hear it Guus

I didn’t understand the documentation

jonas’ it's not overly clear, but the generic principle appears to be: don't broadcast stanzas that are sent to a MUC. Instead, forward it to a JID. Only if that JID gives an 'ok', broadcast the original stanza.

ah. hm.

So that's very similar to what we discussed at the Summit, about having an external spam-checker service that would give yay/nay verdicts on stanzas.

If I'm understanding correctly.

Who was it that made a thing for that?

Or, what it called?

Providence?

Seems to have dissapeared into a black hole.

The thing valerian did? (the jappix author)

Yes

https://journal.valeriansaliou.name/announcing-providence-a-spam-filter-for-xmpp/ it's disappeared though :(

at least it can be choice for who like to use it, and it is not only about spamming, censoring, option for each participant to block private messages with someone and other things

Oh, it's per-occupant? I missed that bit. That's fun.

I imagine pain down that road with MUC MAM

yes

jonas’: Yes.

a world of pain

https://xmpp.org/extensions/xep-0004.html#final-changes we don't seem to add this kind of changelogs anymore do we?

presumably you would find those in the normal version log

So I've got a diff for pubsub/rsm SHOULD-ing a new feature in disco#info of the entity. Now I'm looking at RSM and Order-by and I want to remove the "Determining Support" part, because it doesn't make sense on its own, but that would mean removing SHOULDs or MUSTs (or MUST NOT)

pep., propose the diff

council will figure out a way

k

IMO it should be OK to remove that (IIRC) because the information is useless to a peer anyways

Indeed

Any other XEPs one can think of that should also be amended?

Generic stuff? 0004?

'4 has nothing to do with RSM, does it?

it doesn't, but it's generic like rsm and doesn't mean much as is, does it?

it does

people do send forms directly via messages

Though, TIL <message> can contain <x xmlns="jabber:x:data"/>. Not clue what that means

and clients which support displaying and handling that would... exactly

... expose that feature

I was also reminded of jabber:x:search, that can use forms, rsm, etc. So we'd need to add new disco features on every single spec that can use any of these :/

yes

except if the spec requires it frmo the start

yeah

like muclumbus-search

muclumbus-search will be superseeded by disco#items+rsm+order-by at some point :P

jonas’, or like MAM

Though everybody includes it..

pep., I miss +filter-by-name/address/description in that enumeration

xnamed, I once wrote https://hg.linkmauve.fr/eldonilo/barbecue/ as an implementation of XEP-0284 for the web, I don’t maintain it anymore and the library it’s build upon is dead too, but you may find some inspiration in there. It’s targetting wysiwyg more than plain text, and doesn’t have syntax highlighting or cursors/selections, but that could be added to 0284.

order-by and rsm are sufficient. You "just" need to add a "name"/"address"/"description" filter?

the @by

pep., and then a thing which returns all the info at once instead of having to disco#info each individual result returned by disco#items

pep., disco#items does not support filtering so far

Sure, what I just said

We were looking at adding order-by for disco#items with edhelas

seems reasonable

Maybe you want a filter-by as well, but order-by + rsm should be enough for now? (put relevant items first, ignore the rest)

and once you start with filter-by, you’ll want to write down how that filtering works, which will be its own mess. there’s a reason it’s underspecified in muclumbus at the moment

(it boils down to "whatever postgres does")

yeah..

SQL over XMPP?

Specifying order-by on disco#items of a MUC service is already fun :(

There's only 'creation' and 'modification' filters atm

"What does that even mean on MUC"

pep., nothing useful

What does it mean in PubSub?

Zash, that's defined in the XEP

well to me 'creation' should be enough for MUC disco#items

Zash please add support for https://xmpp.org/extensions/xep-0043.html

How about no

You're holding back XMPP from world domination

Yes it's all your fault.

Prosody is always holding back XMPP, look at ejabberd, they supports 0043 for years

Link Mauve, I will see

Does SQL-Injection count, btw?

So in conclusion, I killed XMPP. Finally the world is ready for my real evil plan, ZMPP!

(how do you pronounce that?)

No talk, only chat!

> Retracted edhelas, are you serious?

It's 100% real news, I heard it on FoxNews

Zash, what about XNPP?

Link Mauve, I found a collaborative editor project on github written in C++ so I think it possible to get some information from it, but we will not implement XEP-0284 on the client as long as it's deferred

xnamed, it won’t go back to experimental without feedback from implementors.

ok

“09:31:46 pep.> Am I going to get punished for daring to update a Final XEP?”, XEP-0030 already got updated in a very incompatible way in the weirdly-named 2.5rc3 version.

A valid parser from rc2 and before could choke on disco#info produced by rc3.

The one in xmpp-parsers had to be updated to remove the explicit ordering restriction.

So maybe we could update disco and caps at the same time and break the world :)

Please don’t.

xnamed, which project is that, btw?

Link Mauve, https://github.com/gobby/gobby

Ah, I know this one, but it’s using a totally different protocol atm.

yes I know

but same idea

who are the the XEP-0284: Shared XML Editing authors here?   • Joonas Govenius    • Peter Saint-Andre    • Tom Pusateri
 so we could discuss it with them first

xnamed, peter is on this chan often enough. I suggest you ask your questions on the standards mailing list though

thanks pep.

does anyone know what `tc` is, as an XMPP server-side software/component?

I always kind of liked Shared XML Editing but I suppose it was too complex.

I quite liked implementing it.

Damn, that was in 2012.

we will not focus on it immediately, it was an idea I did not think the XEP was existed

What about OMEMO support in groupchat as gajim-plugin ( https://dev.gajim.org/gajim/gajim-plugins/wikis/omemogajimplugin#groupchat ) and Conversations?
Groupchat with OMEMO encryption works only in rooms that are:   • non-anonymous   • members-only   • works only with contacts that you have in your roster

Link Mauve, remember https://github.com/fabi1cazenave/sxedit 😀 ?

https://github.com/fabi1cazenave/sxedit/commit/a99facfa291f22d32ae893a4ca505a7a7027270a "Fait tomber en marche.", Some part of France is currently at it :-°

crap, where is my right to be forgotten when I need it

haha

IIRC SXE/sxedit worked really well and editing nodes instead of characters made collaboration much easier as we would "lock" the nodes that were being edited

sonny, yup. ^^

https://xmpp.org/extensions/xep-0059.html#forwards, I'm not sure I understand the following: Responding entity support for paging through a result set is optional. If it does support paging (not just Limiting the Number of Items), then in each page it returns, the responding entity MUST include <first/> and <last/> elements that specify the unique ID (UID) for the first and last items in the page. If there is only one item in the page, then the first and last UIDs MUST be the same. If there are no items in the page, then the <first/> and <last/> elements MUST NOT be included.

"paging" only means a subset of RSM right?

hmm, I guess I'll come back to that once I've read <first/> and <last/>

I wonder what good RSM is for if you take away pagination.

I'm also curious

Maybe you can just get the first N items and be happy with that

Like in matrix

pep.: wat

Oh, I thought I saw a "NOT" in "the first and last UIDs MUST be the same"

Also I am definitely not sure how to picture this: No items will be omitted from pages not yet sent (even if, after earlier pages were sent, some of the items they contained were removed from the set).

2.2, the paging features

Does that mean when the server gets a request, it should store a reference of all items contained in the set, and page through that and not what's actually happening?

It can't store items directly because of the first condition: "Each page of the result set is up-to-date at the time it is sent (not just at the time the first page was sent)."

Maybe we need to define a message DAG that can be linearly paged.

Linked list?

DAG? What would you branch for?

"The responding entity maintains no state" lol, that's a feature of that paging protocol

Doesn't that directly contradict the second rule

Maybe that's why these guarantees are MAY, so that responding entities can pick what they like in there

I added explanation ( https://github.com/xnamed/mod_muc/blob/master/README.md ) about muc-filter very close to the implementation in the ejabberd module I hope that my English is enough or at least to make it easier to you, I had no other way to explain it

pep.: It would likely need to be taken in context of whatever it's used with, eg MAM

Ok I understand now my first question on rsm