jdev - 2021-01-19

In case somebody is in need for funding: https://dapsi.ngi.eu/ Seems to close *tomorrow* :-( > easier for citizens to have any data which is stored with one service provider transmitted directly to another provider. I.e. XEP-0283, I assume? ✏

Probably not worth the trouble, they grant only up to 150000 EUR.

AFAIK nobody implemented "XEP-0283: Moved" so far?

I made a tool once, not sure where it went

debacle: that would have been interesting indeed

283 is meh though

Zash Find it, grab the money and run.

pep. What is the way to go for account tranportability if not that XEP? I'm not aware of other stuff.

Grab the money and spend it looking for it?

Zash, sure, you get the money first and then have nine months of time to find it. Or rewrite it from scratch.

debacle: there isn't

Anyone wanna co-op author a XEP on leaving tombstones after user deletion?

https://wiki.xmpp.org/web/Sprints/2018_November_Dusseldorf/Pad if you grep for "moved", I don't remember many other traces of us trying to fix it. maybe Georg had a branch at some point

what was it that was discussed at summit again?

Zash, what’s there to author? <gone/> and done?

jonas’, that, but more words I guess?

Zash, need a ghostwriter?

Aha!

I was thinking of a (intended) best practices kinda spec. TL;DR: Return <gone/>, keep the marker for n time, prevent new accounts, respond to probes and presence with unsubscribe/s to ensure the global roster graph drops any authorizations.

That got long for TL;DR 😕

s/^/<xep>/;s/$/<\/xep>/ done

I think the best practice for a tombstone is to never allow reuse, on XMPP. There's currently no sane way to ensure that ACLs elsewhere (e.g. rosters, pubsub) don't still contain the JID long after it's been unused.

Mmmm, MUC memberships was a thing I thought of as problematic

maybe services should also periodically probe JIDs they have in ACLs

if <gone/>, drop

(don’t though if the ACL actually prevents something instead of allowing something :))

jonas': You say that, but finding your new JID is blocked from doing useful things only after you have gotten to the point that changing it is impractical is also badness.

Kev, yes, but if <gone/> is in any way under the affected user’s control, it’s an easy way to get around negative ACL entries

Yes. Neither is a solution that works practically.

See previous "you can't reuse JIDs after they're deleted" :)

and you can’t really enforce that the tombstone will exist forever, domains are reused.

servers are reinstalled.

I thought we were talking about a best practice?

I’ve mentally moved on to resilience :)

😀

We can't stop people doing broken things, but we can definitely give good advice - and teling people that JID reuse is practical is bad advice.

Having memberships expire after n time might also help

Kev, exactly, hence I am always *also* thinking into what can one locally do to avoid the impact by people doing broken things ✏

Ah, from that end. Yes.

would be a good time to introduce an account-side list of all places the user is registered with

MIX, PAM, etc?

Ge0rG> would be a good time to introduce an account-side list of all places the user is registered with which will become inconsistent in 3. 2. 1.

flow: well, it should be a superset of those places, maintained by the server, and self-healing

Global distributed self-healing graph!!!!

obviously it is sensible that the user's service knows which things the user is "subscribed" to, hence MIX/PAM do that. but I doubt that this is the answer to the problem discussed above