XSF Discussion - 2018-11-09

Is there a way to persistently put something into your presence for your contacts to see it without keeping a client logged in?

no

use PEP for that, maybe?

What if I want to limit it to individual contacts (speaking for a Moved redesign)

PEP+?

So every of my contacts(' servers) need to subscribe to my Moved node?

you could send an 'unsubscribe' followed by a 'subscribe', because the server MUST store the latter!

one could send a <message><moved/> as well

Ge0rG, ahh, that’s the context

you can send a directed/broadcast presence with <moved/>, but that will vanish as soon as you logout

sending a <moved/> message + the unsubscribed+unsubscribe presence including the <moved/> is probably not bad ✏

Ge0rG, you could send type="unavailable" when you log out

with the payload

jonas’: will the server cache that?

dunno

Maybe

MAYbe?

I feel like it should

Prosody doesn't

pity

it should also cache an 'unsubscribe'

It should, but unfortunately it only MAY.

can has PR 6121?

add erratum

Where to?

dunno, figure out ietf process? ✏

ge0rg: wasn't the server allowed to return your last unavailable presence?

fippo: "allowed to" is not a behavior I can rely on

i think that was allowd but then not used by many servers because it means a reply to *every* probe which makes presence traffic even worse

xep-12 example 5 might do the job

but i am not sure how many servers implement that either. and sending an extra iq to each contact...

don’t servers have to reply to every probe anyways?

fippo: it doesn't even contain the whole presence, just the non-i18n status text.

> Clients accepting the moved subscription SHOULD indicate to the user that that this subscription request was the result of a move operation and because of potential malicious behavior SHOULD NOT auto-accept the subscription without displaying the <moved/> JID to the user. I'm reading this as "clients MAY auto-accept the subscription if they display the <moved/> JID to the user." - am I right in that interpretation of English?

Isn't RFC 2119 language not supposed to apply to UI things?

Zash: yes.

Zash, conventionally

But that doesn't answer my question.

I know it's not as much fun as discussing the applicability of lower-case RFC 2119 to UI, but still.

Clients ShOuLd nOt

Ge0rG: I believe I interpret the quoted text the same way you do.

Thanks.

Implementation recommendation: Tell the user what happens.

What if the user isn't at the screen.

And there is still no clean way to persistently convey a <moved> when unsubscribing.

Send out the informationator bot to search for and .. inform the user.

I think I'll have to <message> it.

Get MattJ to look into https://issues.prosody.im/689 :)

Blocker for all the nice things Ge0rG wants to fix :(

Zash: but this is only for 'subscribe'

is it still not fixed?

nice things are not to be had!

Ge0rG: Oh there's no such rule about keeping the unsubscribe(d)?

Moved doesn't help when I lost my phone along with the autogenerated password it created the account with?

Zash: no.

and no.

Message might be more reliable then.

Yes.

<message> all the things

so send the same payload three times: message, unsubscribe, unsubscribed

Heh

Zash: https://xmpp.org/rfcs/rfc6121.html#sub-cancel-inbound > Implementation Note: If the user's account has no available resources when the inbound unsubscribed notification is received, the user's server MAY keep a record of the notification (ideally the complete presence stanza) and then deliver the notification when the account next has an available resource. This behavior provides more complete signaling to the user regarding the reasons for the roster change that occurred while the user was offline.

Maybe I need to rewrite PARS to use <message> then.

because prosody.

And then it's getting really weird. If a client auto-accepts a Moved, all other clients need to know about it as well.

So they can change message archive etc.

Why?

Ah, yeah

The longer I think about it, the worse everything becomes.

Things are complicated, who knew?

a <message> will only be there in MAM for a limited time

Will it?

Kev: do you have eternal MAM?

I mean, heat death of the universe or something, sure, but possible as long as you're using your account.

Yeah.

Kev: that's great!

My server had a meltdown because I was storing 14 days worth.

isode.com's running with a few years now, I think.

Kev: how many indian trading bots are there on isode.com?

Possibly fewer than average.

I don't know about other public servers, but there is a handful on mine.

with something like 10k msg/day

I suppose we don't have something like an account tombstone, right?

PEP or vcard would be potential candidates to put one in.

Hi, is there a rss feed for https://xmpp.org/blog.html available? I couldnt find one...

Browsers hate this one small trick

I didnt see that "Feeds" on the left, thanks :)

Oh look, there too

In Firefox one can add back the RSS button that they removed because reasons.

what do you mean? rss button in firefox browser or on the website?

in firefox

yeah that is because they removed / are removing rss support in firefox

https://www.ghacks.net/2018/07/25/mozilla-plans-to-remove-rss-feed-reader-and-live-bookmarks-support-from-firefox/

RSS is dead. Together with NNTP and XMPP.

Can the Web be next?

No, the web is way too shittily designed to go down

To shitty to fail!