XSF Discussion - 2022-07-07

Interesting, the list admin is someone from Wire

https://datatracker.ietf.org/doc/bofreq-mahy-mimi-more-im-interop/ more words

Does the second link means that xmpp would have to adopt MLS for groups? It sounds like a good idea since OMEMO doesnt scale that well

Means some folks want to discuss starting a working group to discuss that.

dwd: ? ^

I subscribed

I look forward to those folks writing the code as well

Rough code and running consensus is still the thing, eh?

It's better than endless discussions

Well, I wouldn't say its an endless discussion

No, me neither 😇

yet 😛

but apart from, this, maybe it would make more sense to have our say and come up with what opportunities we have

I'd like to know if you guys have some feedbacks regarding my (small) XEP proposal, Bookmark Pinning https://github.com/xsf/xeps/pull/1182

SGTM, it makes it easier to move in the direction of bookmarks as a synchronization method for joined rooms instead of only those that the user has selected to bookmark

1) It's insane that we have to have a spec to bookmark bookmarks because bookmarks are used for something other than bookmarking. But that's just cosmetic and of no real consequence. 2) We need this 3) extending bookmarks means that naive clients are possibly going to overwrite the extension, but maybe that's fine. 4) We need this

3 should be covered by the spec, baring any bugs, as usual

Maybe I missed it. How's it covered by the spec?

Kev, re 3), the <extensions/> element is required to be left alone by every supporting client, this warranted a namespace bump.

Oh, wait, this is bookmarks:1, obviously.

Yes, I'm being an idiot.

The best kind of idiot, who brings useful criticism. :)

Kev, 0402 can still be renamed “MUC join synchronisation” or something like that.

I’ve heard about some proprietary chat applications using the term “bookmark” to mark messages in the history of a single chat or room.

Well yeah the term isn't proper to MUC

It actually is, as currently defined in our specifications.

Sure, I mean in general

But many clients did away with that term to describe the rooms to rejoin on launch.

Which I think is a neat direction for user-friendliness.

+1

edhelas, a small feedback I have, from a bunch of users who requested that, is to keep a given ordering.

It could be implemented with an integer defining a partial ordering.

Like we used to have priorité in resources :p ?

*priorities

No, like we used to have a non-moving ordering of open tabs.

Instead of the current way of open chats being reordered by last activity, which bothers many people around me.

And how would you solve concurrency regarding the integer order ?

Concurrency is a mess with PubSub anyway, you can just ignore it for now (and forever) I guess.

Ok Movim is already implementing the Bookmark Pinning thing (with its own namespace) for those that wants to try

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/GIA6EJ1pduoJ/image.png

Looks like this

And the pinned room are kept on top of the list

Question though: can you pin 1:1 chats?

Can you bookmark 1:1 chats ?

(and in Movim no)

Conversations supports pinning conversations of any type

Obviously that's not synchronized currently, but if it adopted this XEP it would be weird if only MUCs were synchronized

0402 is only about MUC ?

Supposedly, yes

<conference xmlns='urn:xmpp:bookmarks:1'/>

Generally speaking (though I doubt we can/want to rewrite the world, but it's worth mentioning) it's weird to me that we have two different concepts of a roster that are basically identical and need duplicate functionality re-written for both (the actual roster and the bookmarks list).

Maybe we should release a <bookmark xmlns='urn:xmpp:bookmarks:2'/> ?

Sam +1

That's something MIX actually does improve

They end up with divergent feature sets while requiring that developers basically rewrite the same functionality for both. Pretty much the worst developer experience.

Sam do you have a proposal to solve that ?

We probably can't (or shouldn't). It's just worth keeping in mind as we add new functionality.

Roster is about presences also, bookmarks is not

See also the wide adoption of MIX and other rewrite the world protocols.

Sam +1

Basically my though was "hey we have a fresh bookmark XEP, oh there is extensions, lets add a first extension :p"

But maybe we can generalize bookmarks to any kind of uris, like 1:1 chats or even Pubsub nodes (wild !)

I wouldn't say "can't" we could have a new namespace element that can be put in roster. But since roster is so fundamental and bookmark already exists probably more trouble than it's worth

Plus with vcard4 we now have a xep to put a bunch of roster stuff in pubsub too ;)

Sam, for developers it’s at the library level that a common interface could be exposed.

> But maybe we can generalize bookmarks to any kind of uris, like 1:1 chats or even Pubsub nodes (wild !) Yes please

#LetBookmarksBeBookmarks

And make synchronization an extension?

> At the time, different groups within IETF proposed separate protocol suites (SIMPLE, APEX, and XMPP) because the community could not come to consensus on a single protocol

Lol, well seems like the community eventually did arrive at a consensus though

HTTP

I've never even heard of APEX

But, HTTP/0.9 or HTTP/1.0 or HTTP/1.1 or HTTP/2 or HTTP/3 ?

Uh oh it doesn't seem like Wikipedia knows about the APEX protocol

Search terms "ietf apex protocol" got me https://datatracker.ietf.org/wg/apex/about/

Yea https://duckduckgo.com/?q=apex+protocol is not what I expected either lol

I guess that's an advantage for XMPP, the term isn't reused for a thousand unrelated things like simple, apex, and matrix

So that apex wg has some RFCs published in 2002. IIRC the XMPP WG got started around that time.

> APEX is specified, in part, as a BEEP [1] "profile". I vaguely recognize "BEEP"

um, is jonas still here?

participant list says yes, but you didn't tag him

> moparisthebest wrote: > participant list says yes, but you didn't tag him is it the same jonas’ that used to maintain the MUC search?

says right here how to contact maintainer: https://search.jabber.network/legal

ahh thanks mate moparisthebest wanted to contact him for info about an old incident