XSF Discussion - 2021-07-22

Re the pubsub persistence thing from the other day, I went on an epic quest trough the endless yaks and discovered that the fallback RLU cache returns items in the opposite order from the storage layer. So now I wonder how picky https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve is about the order of items.

.oO(reast lecently used?)

RLWrite*

Zash AH ! :D

could we decide once for all for the "default order" ? most recents on top

That would be easier, but now we have a ton of test cases that expect oldest first, except for the unit tests, that check for the opposite order because they're using the cache implementation rather than the storage backend :/

Such fun!

Would it be a good idea to add a small paragraph to this 0060 section to simply add a "The pubsub service MUST always returns the node items in anti-chronological order (most recent first)" ?

it is indeed an issue for clients like Movim because I'm using this order to display the news articles

The example closest to the section I linked shows chronological, oldest-first order

And we all know that the examples are The Source Of Truth!!! ;)

ok, knowing that there is also this XEP https://xmpp.org/extensions/xep-0413.html to reverse it

so you could implement it "on the way" ;)

but the issue still remains for the "default" case

The storage layer actually flips it already to get chronological order, for implementation reasons.

ejabberd always returns most-recent-first (Holger correct me if I'm wrong)

I think so yes.

The storage layer actually flips it already to get chronological order, for implementation reasons.

Oldest first by default sounds sensible to me, esp. as that's how RSM works …

What about 'published' vs. 'updated'?

There's no "updated"

``` <published>2003-12-12T17:47:23Z</published> <updated>2003-12-12T17:47:23Z</updated> ```

Holger: huh? RSM doesn't define the sorting of results, does it?

Holger, those are elements of the Atom payload, they don't mean that pubsub has the concept of "updated"

Publishing an item with an item id that is already used deletes the previous item, I think

https://xmpp.org/extensions/xep-0060.html#publisher-publish-success has some text

Ah right, yes I meant modification by means of republishing with the same item ID. Couldn't find text regarding the time stamp but whatever.

ralphm: > Holger: huh? RSM doesn't define the sorting of results, does it? Right, it just assumes an ordered set. To me, chronological ordering seems to play more intuitive with RSM's before/after terminology.

Zash: edhelas: I believe that pubsub returns in chronological order, except if max-items is used

actually even with max-items.

chronological (oldest first) seems the more natural to me with XEP-0060 alone (and that match the examples), then there is XEP-0413 (Order-By), which I've just updated by the way.

Holger: XEP-0060 doesn't has a notion of updated, it's just overwriting a item (thus the item is new again). This concept is introduced in XEP-0413 only.

doesn't have

Is Cisco the official owner of XMPP?

no

Who?

wuuko: Cisco is the owner of the Jabber™ trademark, but the XSF has a right to sub-license it.

wuuko: what parts of XMPP are you looking for, specifically? The protocol? The name? The logos?

> Who? Everyone can use it at will

wuuko: not to be harsh--but you ask a lot of seemingly aimless questions on multiple channels, many of which could be answered by reading publicly available materials on your own. it would be helpful to know what your real objective is.

Ok. No problem.

Something came up, will not make it today.

Ok

Is anyone else here?

I don't see dwd or mattj, but it is early here so I'm not sure if I'm just overlooking them

Yeah it looks like we can't have a board meeting this week due to lack of quorum. See everyone next week!

Does the XMPP team generate revenue with sponsors?

What "XMPP team" ? I don't think such a thing exists

Perhaps you mean The XMPP Standards Foundation (the “Corporation”)

> Zash wrote: > Perhaps you mean The XMPP Standards Foundation (the “Corporation”) Yes.

The Treasurer would know for sure.

USSHC provides hosting, is all I'm reasonably sure of. Then there's usually some money that goes to pay for the Summit Dinner.

So how is the software evolving? > Zash wrote: > USSHC provides hosting, is all I'm reasonably sure of. Then there's usually some money that goes to pay for the Summit Dinner.

What software?

XMPP and clients > Zash wrote: > What software?

The XSF doesn't write software

The XSF makes standards in the form of the XEP series, not software.

I guess the scripts etc the Editor uses would count as software... but not XMPP software etc

Is xep what's evolving?

XEPs <https://xmpp.org/extensions/> evolve, XMPP related software evolves...

wuuko: what does "evolving" even mean?

> moparisthebest wrote: > wuuko: what does "evolving" even mean? You can use it to address the vulnerability, add something new, and so on.

No? That makes no sense

> moparisthebest wrote: > No? That makes no sense Why?

as already said, the XSF doesn't write XMPP software. many individual projects do. the XSF discusses [proposed and existing] XMPP standards.

wuuko, you seem to be under the impression that XMPP is a software that the XSF develops or something, and that's full of total misunderstandings

> Zash wrote: > XEPs <https://xmpp.org/extensions/> evolve, XMPP related software evolves... True one was this

And if there was a vulnerability of protocol, will it not be fixed?

the S doesn’t stand for Software?

Thinking of the Jabber Software Foundation?

XSF is The XMPP *Standards* Foundation

Hmm

I am thinking

> I wrote: > And if there was a vulnerability of protocol, will it not be fixed? I'm asking this for continuity.

I *suppose*, a vulnerability in a protocol is a rather abstract thing

xhtml-im was *kinda* cancelled for something similar

https://xmpp.org/extensions/xep-0071.html

So I *hope* xmpp doesn't interrupt me by not getting an update. Looks like it's getting an update.

Because I will create server and will stop for many years

again, that makes no sense

xmpp is not a software, it doesn't get an update

XMPP-based software can get updates, which could be related to XMPP / XEP specification updates

> moparisthebest wrote: > xmpp is not a software, it doesn't get an update Maybe there'll be an error in protocol.

> Zash wrote: > XMPP-based software can get updates, which could be related to XMPP / XEP specification updates Good

> Maybe there'll be an error in protocol. Sometimes some xeps get updates.

Thanks!

But as you seldom see "security fixes" for http but many for browsers and webservers, its the same with xmpp and clients/servers

> many for browsers and webservers, understatement of the timeline

Especially browsers. I know. I first thought of mention it, that it is not remotely as bad with xmpp clients.

arc: while you're here, please reach out to me about the fiscal host stuff, your jid was dead for me :)

> Menel wrote: > But as you seldom see "security fixes" for http but many for browsers and webservers, its the same with xmpp and clients/servers What do you mean, exactly? Why servers and clients are the same for browsers

Are Clients aren't updating

I compared webbrowsers with xmpp clients.

They are

I understand

As a result, I will open a server for a long time interval

Did this page https://xmpp.org/extensions/ live in the xeps or website repo?

> many for browsers and webservers, understatement of the timeline

Does https://xmpp.org/extensions/xep-0060.html#owner-purge-error-nopersist also cover the case where the node has been configured with persist_items=false ?

https://xmpp.org/extensions/xep-0066.html#x-oob hey, what clients would implement this in a way that doesnt require the text in x to be the same as the text in body? Cause conversations behaves like that

Mhm.

> Did this page https://xmpp.org/extensions/ live in the xeps or website repo? website, copying xeplist.xml from the Webserver at build time

Zash: do most clients do that?

It's pretty much the unofficial standard now.

Why?!

Conversations does it.

Oh for goodness sake

That's one way to put it.

jonas’: I had a vision. To steal the column thing from https://modules.prosody.im/ for like the core RFCs and stuff.

But ... I'm going to have to edit the CSS for that, don't I?

Oh how I'd like to throw out pelican and reuse the prosody.im static site generator... ✏

I'd be there to help, if that's happening

Zash, wurstsalat: You have my 95% support - 5% left because I actually cannot professionally evaluate 🙈🤡

Hey there. Do you have to be a member of the XSF to improve old or propose new XEPs?

phryk: Hey. No, no such requirement for participantion.

Membership is mostly a formality for the legal organizational stuff. Tho you do need to be a member to be eligible for some positions.

Thanks for the info, nice to hear. :)

Kind of an unrelated thing, but any of you know about anyone ever running XMPP (whether client or server) on a toaster? :P

phryk: That would be Link Mauve

@ Link Mauve, you did? :D Did you post about it anywhere?

phryk: not an actual toaster, but probably less powerful than any of the """smart""" ones of those days

Yeah, but an actual toaster would make the point so well… ^^

So it can message you when toast is done?

Or it just runs a local XMPP service in case the internet breaks, I don't care. :P

Or would it? Producing enough waste heat to toast toast seems like a bad thing.

I secede that point. A fridge running XMPP is also fine. :P

Better than a fridge participating in botnets :)

Hey, maybe that smartfridge botnet did its C&C over XMPP :P

You know what might help avoid this conversations-centric landscape? On each XEP on the site, indicate what clients implement it

Its remarkably hard to work that information out

E.g. wondering if any client implements 0447 or 0385

qv: I recently wrote a python script getting the list of official client DOAPs and rendering a nice unicode table.

https://rnd.phryk.net/phryk/xmpp-utils/src/branch/main/bin/xmpp-doaptable

(needs python modules requests, colorama and prettytable)

aand it seems to imply that no client actually implements 0044 :P

Clients with a known DOAP are limited to Bruno , Conversations, Dino, Gajim, Monal IM, Movim, Poezio and yaxim tho.

phryk: very nice!

why, thank you. :)

So movim implements 0385 but thats it for both

I have some semi-formed plans on building a suite of modular tools to evaluate some of this stuff, maybe including server compliance stuff, hence the repo name xmpp-utils. :)

Yeah

Sounds good

Yes, but some info is definitely missing from the DOAPs – Conversations for example doesn't note support for 0454 but it's the very thing that defined that behavior.

(OMEMO'd HTTP uploads)

Mhh, I still wanted to open issues about that particular XEP not being noted for Dino and Conversations…

But I'm currently writing my tractate on why lefties should use XMPP :D

Theyre all pretty happy on discord and mastodon i think

Fuck discord, Mastodon I'm on myself. :P

ActivityPub does what it's there for pretty well, I think.

But it's not exactly where the organizing of actions should happen. :P

Matrix is pretty big for lefties too iirc

No idea, never liked it. There's still no proper native client on my OS for it and I don't even know if a good native client exists for any platform…

Or *any* native client on any platform… For all I can tell, it might just be electron all the way down… :F

There's nheko

And some terminal clients

But im not gonna encourage matrix use

Oh nice, even a FreeBSD port exists. Now I at least have an alternative that's not completely shitty when some project only has matrix… :F

There's always... bifröst 😱

Extended your list a bit https://ipfs.io/ipfs/QmSNbiLB1DYKAMMFRaWUbZrDnBcV7u7611sEqzYbrLeB4p

qv if you empty out XEP_LIST it will just show all XEPs it found info on. That also means XEPs not mentioned at all won't show up, tho.

the plan of course is to make this into a CLI parameter, probably with a few predefined sets like noted in https://xmpp.org/extensions/xep-0443.html

Oh i just fetched all the ones that have at least one impl

Irrritating to read though

Everything cool is missing impls

Well, not everything and as I said this info is incomplete because DOAPs is incomplete and many projects don't have DOAPs.

Tho yeah, more implementations would always be nice, especially for stuff like E2E encrypted file transfers and A/V chats. :)

I need to implement oob filesharing (http, 0066) for my client, which is why i was reminded of that dumb conversations behaviour

Not really sure how i can implement recieving without fetching the file first, which is annoying

Im tempted to embed a tiny ipfs server and use that for file storage

Oh wait

I could reupload it to local server and use that i guess

OOB transfers do HTTP? o_O

phryk: https://xmpp.org/extensions/xep-0066.html#x-oob

Thats the media sharing used by most clients rn

With the added caveat of your body must be just the url alone, because something something inputmice

Oh, so what clients usually do is implement 0363 for the upload and then 0066 to communicate the resulting URL to the recipient?

Mhh, does XMPP have something like a User Agent string?

Depends on the context

But yes

I have mod_e2e_policy deployed, like the concept but am missing features, am considering what I can implement…

Ideally I want per-user policies, with an initial value of "optional" and an automatic grace period after which that changes to "required". and to extend it to cover file transfers and A/V chats. But also more specific and context-aware messages when something isn't using E2EE.

For that it'd be nice to be able to automatically recommend alternative clients that do support E2EE for the thing that failed. :)