XSF Discussion - 2021-09-17

Hi

Question about "XEP-0060: Publish-Subscribe" `pubsub#item_expire` : Is this meant to be relative to the creation time of the item or last modification? Both can make sense, depending on use case, right?

true

IMHO, time of last modification makes more sense, because the standard also says: > Note: If a publisher publishes an item with an Item ID and the ItemID matches that of an existing item, the pubsub service MUST NOT fail the publication but instead MUST overwrite the existing item and generate a new event notification (i.e., *re-publication is equivalent to modification).*

also true, but that makes it harder for the use case where you want to publish some information until a certain absolute deadline passes, and you edit that information after it was initially published

so, two deaths, chose one

For singleton nodes and also for blog posts, I assume, that modification is better in most cases. For an absolute deadline, IMHO expiry time is not very good, because it is configured per node not by item. As long as there is no absolute expiry time per item, I would better implement that on side of the publisher, i.e. the publisher should "manually" remove the item, when time comes.

But whatever option, most important would be that the standard does not leave this question open ;-)

debacle, ahh right, fair point

https://xmpp.debian.org:5281/upload/6lQnCKqHOy1J9frJ/xep-0060.patch

debacle, PR it!

flow Uff, one day I need to learn all that modern stuff...

email the patch to the editor 😉

debacle, well you *could* mail the patch to the editor

but, think of it this way: if you PR it via github, you actually incurr cost to microsoft ;)

yes, that's how old people like myself work, inefficiently ;-)

although MS may benefit at the end of the day from it anyway

I'm sure, that MS uses XMPP *somewhere* - so they benefit from everything we do to improve XMPP ;-)

> I'm sure, that MS uses XMPP *somewhere* - so they benefit from everything we do to improve XMPP ;-) I'm sure enough you're wrong

MS is a pretty big company (plus associated companies), and somewhere is a pretty low bar to jump. a single game using XMPP as basis for its lobby would be sufficient…

There was a XMPP gateway in Skype for Business Server but that was deprecated in Skype for Business Server 2019

(see: https://docs.microsoft.com/en-us/skypeforbusiness/migration/migrating-xmpp-federation)

(Beside that SBS is on its way to die as well)

https://matthewwild.co.uk/uploads/screenshot-20210917-1631871982-13372.png

Well done Google

hah! :)

We're doing XMPP and we're still alive 🎵️

MattJ: we must be optimistic, we need better clients. Pidgin should have been improved instead to develop so many other clients to beta and then abandon them. (excuse my horrible english)

The truth is Pidgin never was a great XMPP client

And the same is generally true of all multi-protocol clients

I used Gaim :)) and it rocked. It had voice and video on windows95 and it was working with yahoo google and aol.

I forgot icq

MattJ: FWIW my impression wasn't that bad. Functionality was basic but good enough for most users back then, and it was rock solid, which wasn't true for all clients (looking at all your tracebacks, Gajim). ✏

https://developer.pidgin.im/wiki/GSoC2008/VoiceAndVideo

hehe, although I am not sure if I want to use a client written in a non-typesafe language in 2021

I think I did A/V with Pidgin just fine, some years ago.

flow: Yeah a type-safe language most probably would've avoided most of those Gajim traces 😉 ✏

Holger, you mean statically typed languages would avoided those

Yes yes, I saw that coming.

People identify xmpp with pidgin, for that reason alone we should evolve pidgin and not create a new status symbol. It is like an artifact. Believe me, I know marketing :))

You can not say a religion is 2000 years old if you write a bible every 10 years.

> People identify xmpp with pidgin It is a widely used client but I don't think this is true.

christian: I think the number of ppl identifying Pidgin with XMPP is declining statically (for good) :)

(thank gods)

The Shiny Flakes documentary has lots of scenes where he's using XMPP, even showing addresses like xxx@jabbim.cx And guess what chat client he's using? https://www.imdb.com/title/tt15036416/

jcbrand: probably he was using tails, where it's still part of the base install

He ran a wordpress site on the clear net and had 300kg of drugs in his room (all while being a minor)

Somehow I don't think he used Tails

ope

Fun fact, on his website, he promised not to keep any data on his customers. In reality he had an Excel sheet with IIRC 13000 orders, with names, addresses and what they bought.

Many of those people were later prosecuted and he had to go as witness to those trials

I'm tempted to give more spoilers concerning his terrible opsec, but maybe some people want to watch the documentary. It was quite good IMO

sounds like I should watch this on a day when I need some tragicomedy

This is very OT: This is all normal, you never catch the dealers until you have uncovered and arrested the whole network. The dealer is the last to be arrested, and is usually released immediately, because he uncovers the trail to the next network.

> We're doing XMPP and we're still alive 🎵️ `And when they're dead, we will be still alive`

> Zash wrote: > We're doing XMPP and we're still alive 🎵️ Yes

I don't think Xmpp's going to end.

All good things must come to an end.

https://en.wikipedia.org/wiki/Heat_death_of_the_universe

> Zash wrote: > All good things must come to an end. I have need immortality

Turn evil you say?

What?

Good things → ends Bad things → IMMORTALITY Therefore: Evil QED

Why immortality is bad?

Because it does not end. Good things end. Therefore immortality ≠ good.

Therefore we must turn evil!!11!!1

I think immortality is good

Relaxing

And why would the software that's been around for twenty-two years end?

Assuming it won't, it feels quite exciting how we've been involved with the very first decades of a spec that will live on for billions of years.

BILLIONS

Yes.

Maybe people will remember us as the early pionieers a billion years from now.

Prosody's community repo will hold billions of modules. (hg will cope, it's superior to Git.)

ejabberd will scale to billions of nodes. YY.MM release versioning scheme will become problematic tho.

Sam will be going nuts due to billions of redundant XEPs for publishing avatars.

MIX will be nearly deployed

Eh, there's plenty of time til the end of the century to change the versioning scheme to include more Ys

Sorting versions, otoh... ugh

heh, indeed, the situation is bad enough already, I dread seeing it in a few million years

> MIX will be nearly deployed Despite the billions of "against" and "strongly against"

Has anything changed with the newsletter feed? For some reason, my reader keeps loading all feed items since 2008, marking them as unread…

I was worried that may happen :)

We switched to a new site generator, and some things necessarily changed

It happened twice or thrice already, that's why I'm asking. Were there several changes?

MattJ: have to wonder if Google gives the same answer to matrix fans though...

millesimus, that sounds plausible - the first roll-out accidentally switched to summarized articles, instead of including the full post content in the feed. That was fixed, along with some other things, so it's possible that caused the issue. I'd hope it doesn't happen again though, so feel free to shout if it does.

Will keep an eye on it. :)

goffi

FYI, your email server fails for dkim and dmarc

DKIM: 'FAIL' mit Domain goffi.org DMARC: 'FAIL'

this means it lands in spam

lovetox: oh really? Damn I thought this was properly configured, I'll check it, thanks.

SPF : PASS though :)

on the topic, its sad that not more server support #item_expire

its incredibly useful for stuff like

posting a Status / Current Music etc to pubsub

such information is not very long useful and accurate

and its impossible for clients to remove it in all circumstances

the idea is like whatsapp for example automatically expire it after some time, status for example after 24 hours

lovetox: I think we (as a community) have a decent history of creating server side and client side implementations simultaneously at the same time

If for example you wanted to implement WhatsApp like statuses in your fairly popular client I'm sure server developers can be convinced to implement this

> on the topic, its sad that not more server support #item_expire Funny, a customer asked me to implement this literally yesterday.

(Ah, he's joined to this room and spawned the topic, so not a coincidence, heh.)

Daniel, i asked the prosody team for example to implement this, and i think i got an email a few days ago which indicates they might consider doing it. This was not meant as a rant. I just took the chance, while the option was discussed at the mailing list, to bring awareness how the option might be useful to users. Because its maybe not evident to server devs.

in retrospect i probably should not have used the word "sad". its not really a good fit for the situation.

A customer of mine recently implemented whatsapp like statuses (for an xmpp client) out of band over HTTP instead of microblogging and pubsub. Which is super sad. I would have loved to be paid to implement this with xmpp

I actually think this would have worked out pretty nicely