That's gotta be a typo for jabber.org/protocol tho?
pep.
Ok I'll be careful then
pep.
Probably in examples?
pep.
let's see
Zash
xep-0397.xml has a bunch of xmlns="https://xmpp.org/....
pep.
that's fine, I won't change this one :P
pep.
But yeah that should be fixed
Zash
https://xmpp.org/extensions/xep-0284.html#host
this points to xep 30, so looks like a mistake
pep.
With a bit less effort we should probably add HSTS first
pep.
The 301 is already there
karoshi1has left
pep.
What about: "<p>The ®ISTRAR; shall add 'urn:xmpp:idle:1' to its registry at <link url='https://xmpp.org/registrar/namespaces.html'>https://xmpp.org/registrar/namespaces.html</link>.</p>" ? Is that normative? the registrar uri
Zash
PR'd
pep.
(I changed to https in this quote)
Zash
It is technically a completely different URL, that doesn't have to have the same content as the http: URL
remkohas joined
pep.
err, I don't have access to the nginx that should do HSTS, do I
Technically I can already do that with the nginx inside, but that will send it on both http and https, and it's invalid on http (or just useless?)
Zash
wasn't 80 just serving a redirect?
pep.
I should be able to check for x-forwarded-proto maybe
pep.
Zash, 80, as seen from the outside, yes
pep.
Not from the container
Zash
so
Zash
the outside won't see hsts on port 80?
pep.
So?
pep.
HSTS SHOULD(MUST?) only be on https
Zash
so if the container spits it out on port 80, which is reverse-proxied to port 443 with tls
Zash
then it should all be in order
moparisthebest
Browsers will ignore it over http
pep.
It will also spit it on http. But then maybe as I said I can check for X-Fowarded-For
pep.
moparisthebest, sure
moparisthebest
So it's fine to send it either way
pep.
browsers are as compatible as one can be, because the web if full of crap
moparisthebest
The point is they never visit http again anyhow?
pep.
I just like to do things properly :x
moparisthebest
Don't forget to set up a redirect to https from http, and put it in the preload list :)
pep.
it's already there
Zash
pep.: if the public port 80 is configured to only s/http/https/ then I don't see how anyone can get hsts via http
moparisthebest
Do things properly, the web, bahaha :)
pep.
So I might as well ask iteam directly
pep.
And not put this hack in the xeps repo
pep.
Zash, true.
pep.
Still that's probably not something for the xeps repo
pep.
Maybe the website, but I feel that should go in the host's conf
Zash
Is there a container that contains the conainer-container that holds the 7th proxy?
jmpmanhas joined
UsLhas left
UsLhas joined
pep.
Anyway, I should stop procrastinating the procrastination✎
pep.
Anyway, I should stop procrastinating procrastination ✏
Alexhas left
remkohas left
Zashhas left
rtq3has left
rtq3has joined
mimi89999has joined
rtq3has left
rtq3has joined
j.rhas left
j.rhas joined
Neustradamus
It will be nice to have same base for all without www. etc
lskdjfhas joined
waqashas joined
mimi89999has joined
moparisthebesthas left
jmpmanhas joined
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas joined
wurstsalathas joined
kokonoehas left
rtq3has left
rtq3has joined
j.rhas left
lskdjfhas left
mrDoctorWhohas left
Marandahas joined
Marandahas joined
neshtaxmpphas joined
neshtaxmpphas joined
alexishas joined
alexishas left
lumihas left
matlaghas joined
rtq3has left
rtq3has joined
Yagizahas joined
mrDoctorWhohas left
Yagizahas left
lskdjfhas joined
lskdjfhas joined
Yagizahas joined
mrDoctorWhohas joined
mrDoctorWhohas left
jmpmanhas joined
ThibGhas joined
mrDoctorWhohas left
Nekithas joined
rtq3has left
remkohas joined
lskdjfhas joined
404.cityhas joined
remkohas left
404.cityhas left
kokonoehas joined
vaulorhas joined
thorstenhas left
ThibGhas left
ThibGhas joined
lorddavidiiihas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
j.rhas joined
waqashas left
moparisthebesthas joined
mimi89999has joined
jmpmanhas joined
lhas joined
jmpmanhas joined
sezuanhas left
labdsfhas left
lnjhas joined
sezuanhas left
sezuanhas left
j.rhas joined
remkohas joined
andyhas joined
kokonoehas left
kokonoehas joined
Alexhas joined
Marandahas joined
Marandahas joined
andyhas left
andyhas joined
vaulorhas left
Tobiashas joined
lorddavidiiihas left
lorddavidiiihas joined
ralphmhas joined
kokonoehas left
Steve Killehas left
neshtaxmpphas joined
architekthas joined
Steve Killehas joined
kokonoehas joined
architekthas left
jmpmanhas joined
frainzhas left
frainzhas joined
lovetoxhas joined
frainzhas left
frainzhas joined
APachhas left
APachhas joined
karoshihas joined
sezuanhas left
Guushas left
edhelas
I'm really tired of refusing OMEMO requests
edhelas
I'm thinking of hardcoding the body detection and starting to reply automatically
Guushas left
Ge0rG
edhelas: just blacklist the OMEMO node on your PEP
lovetox
whats a OMEMO request?
edhelas
>
I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo
labdsfhas joined
lovetox
tell your contacts to disable omemo?!
thorstenhas left
edhelas
yes, one by one :) if at one moment they move to conversations
Ge0rG
lovetox: that's O(N*M)
Ge0rG
with N=number of contacts and M=number of devices each contact has
edhelas
I'm not there to do "remote xmpp client configuration over human written messages"
lovetox
hm in Gajim you can deactivate publishing keys to the node
lovetox
but yes this problem exists because you use a client that supports omemo ..
Ge0rG
because you once used such a client
Ge0rG
if you are on prosody < 0.11, you can restart your server to "fix" it
edhelas
yes I do use Conversations sometimes, and Movim 95% of the rest of the time
ralphm
pep.: there are some, mostly deferred/retracted, XEPs that use http://xmpp.org/ as the start of their namespace. I'd leave them be. If we ever resurrect them, they'd have to go with a urn one anyway.
lovetox
fastest way would probably to set the devicelist node to whitelist
Ge0rG
edhelas: write a Movim plugin that subscribes to the siacs namespace and removes all devices
Ge0rG
or what lovetox said
lovetox
Ge0rG that does not help
lovetox
as devices are instantly republished
lovetox
you can configure nodes in Gajim 🙂
ralphm
pep.: and probably everything that still has shtml in a link should get looked at.
jmpmanhas joined
moparisthebesthas joined
vanitasvitae
edhelas: does movim support Explicit Message Encryption?
edhelas
vanitasvitae I as looking into that
vanitasvitae
You could use that to determine, if a message is omemo encrypted or not
vanitasvitae
Might be better than to check the body
edhelas
conversations is adding the tag ?
vanitasvitae
Pretty sure it does
edhelas
ok
Ge0rG
lovetox: how do you configure PEP in Gajim? I've opened the "Configure services.." menu on my server, but there are no items listed and the buttons are greyed out, except for "Close"
lovetox
because your server does not support configuring nodes
Ge0rG
lovetox: would be awesome to have that displayed in that box
lovetox
yes once i rework the dialog, its still from ancient times
Ge0rG
Ah, the Good Old Times!
pep.
What happened about the LC on 345 BTW, did I miss any decision made about it?
goffihas joined
Ge0rG
pep.: I suppose the Board needs to vote on advancing it next.
Ge0rG
Or maybe somebody can make a PR incorporating LC feedback
thorstenhas left
mimi89999has left
Ge0rG
dwd: I would kindly ask you to put https://github.com/xsf/xeps/pull/752 and XEP-0410 advancement on the next Council agenda. cc jonas’
kokonoehas left
Zashhas left
moparisthebesthas joined
moparisthebesthas joined
kokonoehas joined
igoosehas joined
igoosehas joined
ralphm
Ge0rG: with the Summit happening, we haven't had a meeting to discuss the LC feedback on XEP-0345 yet. Thursday is the first opportunity.
Ge0rG
pep.: ^
Ge0rG
There was also a Board PR that Council was asked to look into.
ralphmhas left
Zashhas left
architekthas joined
wurstsalathas joined
architekthas left
rtq3has joined
j.rhas joined
goffi
hey there. I was thinking this morning, it would be nice to have a QR code with my jid in it on my website, so people could get it easily from phone, and it would be nice to have a way to make it easy to recognise. It's possible to put an image inside QR codes, so would not it be nice to agree on something (e.g. putting XMPP logo inside) so we could know immediatly "OK this is a XMPP identifier"? Would it make sense to have an informational XEP on this?
tahas left
tahas joined
Ge0rG
goffi: yes, you can increase the FEC on QR codes and then just bump some picture over the middle
Guus
sounds like a fun little shareable service.
goffi
Ge0rG: FEC?
jonas’
(forward error correction)
pep.
Wasn't it "the image isn't part of the standard, it's just ignored with error correction"
Ge0rG
goffi: forward error correction. Also related: https://github.com/ge0rg/easy-xmpp-invitation
jonas’
although I’% not entirely sure that’s the correct term for QR codes✎
pep.
hah, right
jonas’
although I’m not entirely sure that’s the correct term for QR codes ✏
goffi
I know it's possible, that why I'm proposing it, we don't need much characters for a jid.
Ge0rG
jonas’: but it still is FEC.
jonas’
ok
Ge0rG
just because people invent new fancy names... 🤷
pep.
goffi, what do you want to do with "a JID"?
pep.
Add as contact?
goffi
pep.: yes
goffi
not only on website, on visit card too
Ge0rG
goffi: what if the person scanning the code doesn't have a Jabber client yet?
goffi
I just want a way to recognise immediately "oh this is a jid"
pep.
goffi, have a look at what Ge0rG pasted
Ge0rG
I'd put a Jabber lightbulb in it.
pep.
We can probably just put a QR code there
goffi
Ge0rG: it's the same issue with a xmpp:myjid@example.net link.
pep.
https://yax.im/i/#vladimir@xmpp.example
goffi
my point is just to have a way to recognise the QR code as XMPP related.
Ge0rG
goffi: I've heard you are good at webdev.
mightyBroccolihas left
mightyBroccolihas joined
goffi
using http or xmpp is an other thing. There are issues with http (you have to keep a service, and it won't be catched by registered client). But that's not the point of my idea, I just wonder if it would make sense to agree on a way to recognise XMPP QR Code (image inside is one thing, we could also play with colors).
Ge0rG
> it won't be catched by registered client
yaxim will catch both yax.im and conversations.im landing pages
goffi
Ge0rG: what do you mean ? I'm working with web sometimes yes, and on a XMPP web framework.
pep.
I'd have a QR code with the XMPP logo (to add to the bikeshed discussions)
Ge0rG
goffi: the easy-xmpp-invitation project is looking for volunteers 😁
goffi
Ge0rG: and what I have gajim ?
Ge0rG
goffi: how do you scan images in Gajim?
debaclehas joined
goffi
Ge0rG: I would love to help on that, but I'm already close to burn out with my paid job + work on SàT + all side stuff (like preparing FOSDEM)
Ge0rG
goffi: alright, thanks anyway :)
rionhas left
rionhas joined
goffi
Ge0rG: I was mentioning gajim for the contact link, a xmpp:toto@example.net will work there, https://yax.im/i/#vladimir@xmpp.example wont
rtq3has left
rtq3has joined
thorstenhas left
Ge0rG
goffi: on my OS, Gajim doesn't handle xmpp: URIs
goffi
is it possible with QR code to have 2 links ? A http: one and a xmpp: one ?
Ge0rG
nope. But the landing page contains an xmpp: link ;)
goffi
what if the size is down ?
goffi
site*
pep.
Then it's down I guess
delehas joined
goffi
xmpp: will still work. I mean I get the point with https: link, and I agree on most of them, but the xmpp: is the standard way of doing, it's not linked to an entity, in short it has many advantages too.
goffi
it's not linked to a client or service*
pep.
goffi, what if your xmpp server is down
Ge0rG
goffi: it's got many advantages, but it doesn't work for normal people.
pep.
Will the other server resend the subscription request(?)
goffi
pep.: it won't prevent you to add the contact, after the subscription will happen when it will be up again.
Tobiashas left
pep.
goffi, ok. I wouldn't mind having the xmpp: uri in there, but then you only target people already present on xmpp
goffi
best way would be to find a way to have both in a easy way, but doesn't looks like possible.
pep.
(I agree we're mixing two issues, but I don't know how to entangle them)
mtavares
have two qr codes...
mtavares
just to make it more complicated.
pep.
mtavares, I think that's be even more confusing
mtavares
using a http link works well enough, me thinks.
pep.
"So which one is it??" "It's the same" "Why do you have two then?" -- my mom
goffi
https://qr-creator.com/multiple-url.php
goffi
it seems possible
mtavares
ahh.. interesting.
pep.
goffi, it's just text right, you put whatever format you want in there
Wiktorhas left
Tobiashas left
Wiktorhas joined
jonas’
pep., QR codes have multiple subformats for different payloads
pep.
I see
jonas’
partly because they use different codes for different payloads to save bits
pep.
And of course this website only accepts URLs
Zashhas left
pep.
not XMPP URIs
goffi
ah it's just redirecting and shows the 2 links
goffi
pep.: yes I know, but the QR code readed need to know how to handle both.
mtavares
it's just a https link to qr-creator.
goffi
mtavares: yes, so not good :(
delehas left
Tobiashas left
Ge0rG
https://op-co.de/tmp/georg@yax.im-bulb.png
Ge0rG
https://op-co.de/tmp/georg@yax.im-xmpp.png
goffi
I like more the second one
goffi
it's neat :)
pep.
yeah me too
Ge0rG
This is the moment to complain about our well-known marketing name being absolutely burned, and our official protocol name being too technical for regular people.
pep.
Maybe just remove the "XMPP" from there
pep.
So you don't have to pronounce it.
goffi
yeah the logo only is fine I think
goffi
also I think the text could be used for something else.
goffi
for instance, would it make sense to distinguish QR Code depending on their use: for instance a contact to add, or an ad-hoc command to execute, or a pubsub service ?
goffi
so you would but the XMPP logo, and "contact" under it instead of "xmpp"
Ge0rG
did I mention that normal people in our region consider QR codes as something awkward?
goffi
why ?
Ge0rG
dunno
goffi
nearly everybody is getting use to it, it's a nice techno
Ge0rG
http://picturesofpeoplescanningqrcodes.tumblr.com
Andrew Nenakhovhas left
ta
I have it on my applications as vCard. I still hope some technical employer finds it nerdy.
Zashhas left
Ge0rG
ta: do you have a utm tag in it?
ta
well, i don't have a link in it, so no...
ta
I mean application as in paper/pdf. QR-code being just contact information as vcard.
ta
But i should consider tracking when applying at some online shops. they like everything i try to block ;-)
lnjhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
rtq3has left
rtq3has joined
lnjhas joined
Zashhas left
lovetox
woever wrote me a pm here, i cant answer because converse does not support pm 😃
ta
<-- is just asking about the gajim muc not beeing reachable from some servers.
lovetox
ta, would be interested what the error is
lovetox
im joined and im on jabber.at currently
equilhas joined
ta
if you guide me. gajim and xml console didn't give me much feedback.
ta
you can guess my JID, so we don't spam here. I am using trashserver.net (no comments on that name ;-)
lovetox
but it should, restart gajim open xml console, join the muc and maybe wait for 1 minute, whatever the servers timeout is, at one point your server should inform you why its not possible to connect
lovetox
otherwise ask the admin
architekthas joined
Zash
lovetox: Looks like a IPv6 problem, please try to fix it.
lovetox
can you be more specific
lovetox
im not the server admin, but i can tell him
Ge0rG
If only XMPP servers could gracefully support both IPv4 and IPv6
Ge0rGlooking at Zash
architekthas left
architekthas joined
Ge0rG
lovetox: traceroute to conference.gajim.org (2001:bc8:342f:101::1), 30 hops max, 80 byte packets
...
5 * * *
6 2001:bc8:400:1::8e (2001:bc8:400:1::8e) 27.964 ms 28.068 ms 28.263 ms
7 2001:bc8:400💯:26 (2001:bc8:400💯:26) 25.912 ms 26.035 ms 26.204 ms
8 * * *
...
tahas left
pep.has left
Zash
Ha. Blame Link Mauve
Ge0rG
Zash: is he behind gajim.org?
pep.has left
pep.has left
Link Mauve
No I’m not.
Zash
No, why I bumped a timeout back up to the point where it gives up completely before trying the next IP
Ge0rG
Zash: you bumped Link Mauve?
Ge0rG
can't you unbump him?
Zash
Link Mauves toaster was too slow for the low timeout
ta
Well is this the cause already? I restarted gajim, have a very spammy xml console...
Ge0rG
Zash: can't you also increase the *other* timeout then?
Marandahas joined
Marandahas joined
Ge0rG
Zash: it's a bit shortsighted to break connectivity for all users of prosody just because of Link Mauve
lovetox
ta i reported it to asterix but will not be fixed immediatly
Zash
Actually, this specific configuration still works because the write timeout here is 60s and the "give up completely" timeout is 90s
Zash
But ... this varies
dwd
Hi all. Do we have an incremental update for disco#items and things? I've a feeling that Sem Whited documented something that HipChat did a while back but I can't find it.
jonas’
what do you mean by incremental update?
neshtaxmpphas joined
ta
lovetox, thanks. No hurry. I was just surprised that nobody "cared" in all the other XMPP-centric MUCs ;-)
dwd
So if I have cached, for example, all the disco#items, and I now want to find what's changed instead of downloading the entire list again.
dwd
Sorta like XEP-0237 for Disco.
Zash
lovetox: The prosody module mod_bidi might help a bit, since it reduces the number of connections that can fail
Zash
dwd: Isn't that caps?
Zash
Or you want caps on ... things?
Zash
Or disco-sub or whatsitcalled?
dwd
Not caps. Though caps on ... things would be nice, actually - good plan.
dwd
But caps doesn't do disco#items.
Zash
Right
Zash
Did caps2 do that?
Zash
I'm sure we discussed some semi-recursive caps thingy recently
dwd
But yeah, if I have 1.2 quadzillion MUCs, I'd like to just fetch the three new ones and not the 1.2 quadzillion over again.
jonas’
caps isn’t really incremental, either
Zash
Yeah. Figuring that out would be nice.
dwd
jonas’, Yes, indeed.
rtq3has left
jonas’
disco#items versioning essentially
dwd
I can't recall if we decided that Sam's proposal should be a XEP or even if he submitted it.
Zash
I was leaning towards not returning complete results in disco#items at all and defering to some search interface
jonas’
I don’t recall anything in that direction
Ge0rG
RSM!
Zash
I only recall that there was "disco-(pub)sub"
dwd
But otherwise, I'll do a ProtoXEP based around '237's design if there's interest.
dwd
Ge0rG, RSM is good for paging, less good for incremental update.
Zash
RSM is also weird if items can be removed
Guus
dwd hipchat has a couple of features documented here https://docs.atlassian.com/hipchat.xmpp/latest/xmpp/rooms.html
Guus
the room push comes closest to what you describe
dwd
Or... I could do it based on pubsub, and then list disco#items things in a pubsub node... somewhere.
Guus
(it also does something with service discovery - but that does not seem to match your description)
Zash
dwd: But if you have 1.2 quadzillion MUCs, having a cache of them locally is probably not fun anyways
Ge0rG
dwd: did we solve the multiple-items-per-node pubsub problem yet?
Zash
Ge0rG: What problem is that?
dwd
Zash, True, but I have a way of having a set of MUCs I'm interested in anyway. The problem is that I have a lot of them.
dwd
Zash, Also, caching 1.2 quadzillion items is not fun, but fetching them anew every time is even less fun.
jonas’
dwd, wouldn’t some type of search interface make more sense then?
dwd
Perhaps, but I do have a few cases where I want all the disco#items.
pep.has left
j.rhas joined
delehas joined
flow
dwd: I am not sure, but you are maybe looking for https://xmpp.org/extensions/xep-0366.html
flow
But I guess for a delta sync of disco#items you probably want something like disco#items versioning…
Zash
How many implement the incemental roster versioning thing?
j.rhas joined
delehas left
delehas joined
karoshihas left
karoshihas joined
jmpmanhas joined
lumihas joined
j.rhas joined
Nekithas left
Nekithas joined
tahas left
ralphm
dwd: having a pubsub node to represent available channels would definitely be interesting.
jmpmanhas joined
ralphm
dwd: with RSM, it would be much easier to keep lists on the client side in sync.
404.cityhas joined
dwdhas left
ralphm
We kind of already have a specification for this with `pubsub#subscription_type` with the value of `nodes`, and using that in subscription options towards the root node.
Ge0rG
dwd: did you receive my message further above regarding Council Agenda additions for tomorrow?
ralphm
https://xmpp.org/extensions/xep-0248.html#notify-items suggests there's a `<create/>` element in pubsub#event to be used for notifications, but the schema in XEP-0060 doesn't current have that.
lhas joined
dwdhas left
lhas left
architekthas joined
delehas left
architekthas left
architekthas joined
goffi
I have no time to check it now, but is not this RELOAD protoxep doing something similar to jingle?
lhas joined
Zash
Based on what dwd wrote, I wonder if it's rather something for the IETF?
j.rhas joined
lskdjfhas joined
architekthas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
neshtaxmpphas joined
lorddavidiiihas joined
Guushas left
Alexhas left
lhas joined
ralphm
Too bad the date on the inbox entries are all from yesterday.
pep.has left
pep.has joined
pep.has joined
debacle
goffi, to me XOR looks more like 0174 (Serverless), but with NAT traversal
jonas’
XOR depends on '174 AFAICT
goffi
OK, I've just overlooked and it looked like a way to establish a stream.
goffi
interesting then, I'll check that later.
moparisthebesthas joined
Tobiashas joined
moparisthebesthas joined
efrithas joined
sezuanhas left
j.rhas joined
moparisthebesthas left
krauqhas left
equilhas left
equilhas joined
krauqhas joined
dwd
Ge0rG, I've not noticed it, and would welcome an email. Travelling tonight at short notice, and I'll try to do the agenda stuff on the train.
Tobiashas left
jmpmanhas joined
Ge0rG
dwd: sure thing
dwd
So, XEP-0366 is more or less what I was after. I think including caps, though, is probably interesting too.
Zash
"I have stuff with caps hash xxxx, what's changed since?"
> Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0
> Changes from derived property value UNASSIGNED to either PVALID or DISALLOWED.
andyhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
debaclehas left
j.rhas left
j.rhas joined
edhelashas left
edhelashas joined
alacerhas left
alacerhas joined
matlaghas left
Ge0rG
In the context of RELOAD, I'd suggest defining an XMPP wire-format to exchange X.509 CSRs and CRTs, which could be immediately plugged into a XMPP JID-identity CA
dwd
Zash, No, caps can be an all-or-nothing for disco#info. But it'd save me a huge amount in this particular instance. I think an entityver thing would help with disco#items, though.
vaulorhas joined
lorddavidiiihas left
j.rhas joined
lorddavidiiihas joined
goffihas joined
lovetoxhas left
Zashhas left
Nekithas left
Nekithas joined
waqashas joined
ThibGhas joined
ThibGhas joined
Nekithas left
Nekithas joined
efrithas left
ralphm
MattJ: so RFC 7622 will need an update?
ralphmhas left
Nekithas left
Nekithas joined
Guushas left
goffihas joined
Zashhas left
Ge0rGhas left
Zashhas left
lovetoxhas joined
pep.
ralphm, thinking about <gone/> again for <moved/>, and MUC affiliations/PubSub subscriptions. I can't just return <gone/> for everything that comes pinging my account for privacy reasons. And my server doesn't know (could know, but allegedly doesn't track) these subscriptions, so..
lnjhas joined
ralphm
Well, if you want to leave some kind of tombstone, but only to selected people, you kinda have to keep the former relationships, whichever way.
alacerhas left
pep.
It will work for contacts, because we have the roster
pep.
But that's about the extent of what the server keeps track of, in the general case
ralphm
I suppose for pubsub subscriptions it might be harder indeed.
jonas’
and MUC affiliations
pep.
Not even talking about server shutting down etc. yet
ralphm
But this is one of the reasons why dwd suggested PAM, so that your server keeps track for you. When you move, you could take that with you.
pep.
(I'm thinking about not considering this use-case for a first rewrite of <moved/>)
pep.
PAM?
ralphm
https://xmpp.org/extensions/xep-0376.html
Ge0rG
pep.: the hard question with roster is how to tell multiple clients of your friend, if the first client will replace unsubscribe your old JID.
pep.
Ge0rG, yes I got that, you don't have to repeat it over and over, that wasn't the question
pep.
I know we need a tombstone of some sort, and that was discussed
Zash
pep.: This came up at summit, about needing to keep the roster, or maybe some magic hash of it
pep.
Zash, "this"?
Ge0rG
you could create a PEP node with a whitelist populated with your roster when moving.
Ge0rG
pep.: what's the question then? Who is allowed to see your tombstone? Either everyone or old-roster-only, I suppose
pep.
Ge0rG, no that wasn't the question
pep.
Ah well, yes sorry
pep.
But not for the roster
pep.
I'm asking for muc affiliations and pubsub subscriptions (read the question)
Ge0rG
ah!
ralphm
so couldn't you whitelist the muc services on your bookmark list (private storage or PEP) and the pubsub nodes you have received notifications from?
Ge0rG
there is no way to enumerate all your MUCs and PubSub subscriptions, unless your PAM keeps track of them all, from day 1
pep.
Using bookmarks for MUC seems interesting
pep.
But yeah for PubSub we'd need PAM or sth
Ge0rG
bookmarks probably contain the relevant subset (what do you care if you are affiliated with a MUC you never joined)
ralphm
*also*, besides leaving a tombstone, there's no reason why you couldn't send a presence with forwarding address
pep.
presence is ephemeral
ralphm
not for muc rooms
Ge0rG
it might suffice to let PubSub and MUCs know.
ralphm
i.e. you only need to have it received once
Ge0rG
but you don't know where to send, in the first place
pep.
Technically the server can know
pep.
But yes that has to be done from day1
ralphm
wouldn't you likely cover this by the list of muc servers that you frequent rooms of?
ralphm
unless 100% is your goal, in which case good luck
jonas’
gateways & transports are another topic
pep.
I would hope services GC after some time being unresponsive
jonas’
a tricky one, actually
jonas’
I wouldn’t want to loose my biboumi MAM because I moved accounts
pep.
hmm.
pep.
We're really trying to sort all the problems in the world at the same time :/
pep.
This thing is never going to progress
jonas’
I’m calling it "enumerating"
jonas’
I don’t expect your proposal to solve all of them
pep.
jonas’, I guess it's time for a client-side MAM? :/
jonas’
but it should enumerate them all, and clearly distinguish between those which are solvable and solved, those which are likely solvable and deferred and those which are not likely solvable
jonas’
client side MAM?
pep.
So that you can just ditch the server archive once you've fetched it, and then have your mobile ask your desktop client for archives
jonas’
yea, no
pep.
Why not
tahas joined
jonas’
I don’t want to implement the server side of MAM things in a client
jonas’
huge complexity, especially with Smart MAM ahead
pep.
True..
jonas’
(and how about the clients which have the "I don’t want to store everything locally anyways" philosophy)
pep.
It's really not the first time I hear about it though
jonas’
yeah, you hear from it mostly from crypto fashionistas
pep.
Sure
jonas’
who want to solve the PFS problem with a huge pile of complexity
Ge0rG
...and then end up talking with people who just dump everything into sqlite
pep.
Anyway, this is not a crypto party, the topic is different
Ge0rG
but you can't just just expose your new JID to every entity that claims to be a pubsub node.
jonas’
in any case, client side MAM won’t solve the biboumi case
jonas’
you don’t want to have that all stored on your phone anyways
pep.
jonas’, it would yes? I think
ralphm
I see this problem as moving house. You let your friends know. In the Netherlands you have a service that informs (selected) entities of your new address so they can update their records. Also, the occupant typically temporarily forwards stuff to you.
ralphm
(new occupant)
goffihas joined
ralphm
You never reach 100%, and that's fine.
Ge0rGhas left
pep.
Right. So we're inevitably going to drop mail, but yeah it's fine
pep.
They'll recontact us, (or not)
ralphm
And the rest of it is usually a thing you solve socially, out of band, not technically.
alacerhas joined
pep.
Ge0rG, would you be ready to compromise on that <moved/> thing, or do you want to get all the use-cases into the one XEP
pep.
If so, I'll split efforts because I'd like to have something ready by 2025 not 2030
pep.
(I'm being generous)
Ge0rG
pep.: you know, I was like you, back then in 2018. I thought "how hard can it be". But then I started work. And I realized...
Ge0rG
So, what exactly do you want to compromise?
Zash
pep.: privacy problem of gone, needing to keep the roster
Ge0rG
Also persistent PEP with a configurable access model.
pep.
I want to drop the "My server is offline" use-case. I am not sure I'll be able to support "My server is scheduled for shutdown" entirely either, because we need tombstones
pep.
But I guess if your server shutdown is planned in 6 months time, that's already quite enough time to migrate most of your contacts
Ge0rG
pep.: do you want to drop muc affiliation and pubsub?
pep.
I don't know. At the moment I see it as something the server will have to keep track of for us, unless you have a client-side solutions
Ge0rG
Do you want to support users migrating from prosody < 0.11?
pep.
non-persistent PEP?
pep.
No I don't care
pep.
People please update.
pep.
Well, there is MAM, I can do with that if you really want
Ge0rG
A cryptographic identity overlay network that works over XMPP as the routing layer
pep.
yeah no thanks
alacerhas left
pep.
I wouldn't mind trying to make it future proof, as in, compatible with a possible crypto thingy that would come on top, if that's possible. But I'd like to have something out soon
pep.
Actually PEP/MAM are not necessary if we do <gone/>, on the old server.
Ge0rG
The old server must support it then.
Ge0rG
Also access permissions
pep.
The old server must support RFC 6120?
pep.
I hope it does
pep.
Ah ok I see
pep.
hmm, we can prompt for support, and if not fallback(?) how is that
Ge0rG
> Also access permissions
Ge0rG
Is there a protocol to *configure* gone on your account?
pep.
Yes, we can prompt for support on the old server, and if not PEP/MAM?
alacerhas joined
pep.
We talked about adding that to IBR, so that'd be a new thing indeed
MattJ
The problem with PEP is that it needs to be explicitly checked or subscribed to, and works on a client level
Ge0rG
So you'd say the default access permissions for <gone/> will be the user's last roster?
MattJ
<gone> errors in response to probes are much nicer
MattJ
But do require support from the migrating server
pep.
MattJ, sure, they all require support on different level..
pep.
*Somebody* has to support *something* :(
Ge0rG
pep.: sending messages to all your contacts doesn't.
pep.
Ge0rG, yes, clients need to understand MAM, and the moved payload
Ge0rG
pep.: I wanted to make a protocol that gracefully degrades if it's only supported by clients on both sides.
pep.
How far did you get
Ge0rG
pep.: messages with a moved payload from the old and from the new account. MAM / Carbons on the receiving side as faux persistence.
pep.
(all these french words)
Ge0rG
pep.: maybe a private PEP node on the receiving side where the first client can store the Moved from-to pair
pep.
yeah I remember these discussions, and I'm fine with that
pep.
I thought that was dealt with already
Ge0rG
But then there is a nice race condition on populating that PEP node.
rtq3has joined
Ge0rG
pep.: not written down yet.
pep.
Ok, let's do it then
Ge0rG
pep.: you want to continue the work? I can commit and push my last sad state.
Ge0rG
A compliant server could process a Moved PEP node on your account, and send a gone error to entities that are allowed to read that pep node
Ge0rG
Or maybe always send the gone, but only fill the JID if permitted.
sezuanhas left
pep.
yeah that's details to me at this stage
pep.
hmm,
Ge0rG
pep.: https://github.com/ge0rg/xeps/tree/xep-0283
Ge0rG
that's the code behind the rendered version I forgot to tell you before Summit.
pep.
k
goffihas joined
pep.
I wouldn't actually mind only including compliant servers or clients in my assumptions, tbh
pep.
Deployment is an issue, and we all know that. My goal is not to solve this. (/me eyes non-rolling release distributions)
Zashhas left
rtq3has left
rtq3has joined
Zashhas left
Zashhas left
dwdhas left
moparisthebest
but a feature that only requires clients to upgrade will be adopted faster, especially if users want it, because it's fully under their control
pep.
But their contacts also need to support it
pep.
So maybe not that fast
moparisthebest
not if they can fall back
moparisthebest
like 'oh you don't support automatic roster migration? ok send message "hi I was x@x now I'm y@y"
Ge0rG
with the main reason for this being "abandonden servers" I'd pull the line at modern client support
pep.
Ge0rG, it's not my main reason fwiw
lskdjfhas left
pep.
My main reason is services like quicksy, or any other public services, which are great for adoption, but then users might want to move away from that
Ge0rG
I've heard there are ~250 users on Quicksy.
pep.
Sure
pep.
"or any other public services"
moparisthebest
then it has to be a client-only feature
pep.
moparisthebest, why does it have to
moparisthebest
public services that don't want people to move away would just never enable it?
moparisthebest
especially if they get $ from users, directly or data mining (google)
pep.
Yeah I'm not considering evil services tbh, that's another can of worms
moparisthebest
I'm not talking about evil
pep.
Why would they block then
moparisthebest
client-only doesn't work with actively evil either, they can block stanzas etc
pep.
Indeed
pep.
Any server can just block the PEP node
moparisthebest
I'm talking about "should I download and install/configure this plugin that makes it easier for users to leave?"
moparisthebest
why would they do extra work for that?
pep.
moparisthebest, if it's a PEP node it's no extra work
lskdjfhas left
moparisthebest
so that's client-only?
pep.
PEP is not client-only no
pep.
Neither is MAM. They all require server support
moparisthebest
yea but it doesn't require specific server support is all I meant
pep.
Yes it does
moparisthebest
not for this specific thing
Yagizahas left
moparisthebest
just PEP in general that's used for lots of other things?
pep.
Yes yes
pep.
So here's your reason why they would set it up
pep.
So the feature can require server support
moparisthebest
yea that all sounds fine then
moparisthebest
I just meant if it required all servers to upgrade before it was useable, it'd be worthless and never adopted
moparisthebest
think MIX
pep.
Well there are still prosody < 0.11 out there, and it's going to be the case for a while
rtq3has left
moparisthebest
so you are, vaguely, publishing a pep node as old@old.com saying you've moved to new@new.com ?
pep.
Yeah. And that tombstone should stay up for your contacts' devices to see.
lskdjfhas left
lskdjfhas left
moparisthebest
I tended to like what Ge0rG called a 'cryptographic overlay' better, it's maybe a bit more complicated, but not too much
lskdjfhas left
ralphmhas left
pep.
I don't mind having that as a goal for later, in a different XEPs, with different goals (including moar uses-cases)
mtavareshas left
moparisthebest
vaguely, you publish a public key, your contacts save this (public key for old@old.com), then if a new account sends a subscription request with a message "I was old@old.com but now am new@new.com" signed by old@old.com's key, you know to update it
moparisthebest
not that much more complicated, supports everything that does plus the (I would think) common usecase of a server disappearing
lskdjfhas joined
pep.
You don't actually need crypto fwiw
lskdjfhas joined
pep.
Except if your old server is _already_ offline
pep.
But then you're probably not in a good position anyway
moparisthebest
that seems like a valuable usecase to support though
pep.
Yeah, I'm not worried about it for now, but you're welcome to
moparisthebest
so is yours, uh, lazy
pep.
And you should have preemptively declared your key if that's the case
moparisthebest
it relies on all your contacts checking your old PEP node every time?
pep.
They can check it once and be done
moparisthebest
once every time the client connects or?
pep.
Once they've acked it
j.rhas joined
moparisthebest
it doesn't react to being sent a message though?
pep.
I don't understand
moparisthebest
it checks pre-emptively for all roster contacts?
pep.
"it"?
moparisthebest
your client
pep.
Yeah, you +notify on the node
lskdjfhas joined
moparisthebest
so when a client logs in it has to check them all too I guess
j.rhas joined
j.rhas joined
lskdjfhas left
pep.
them?
moparisthebest
xep-27 already announces a key even, 'moved' could just define a signed payload for "I've moved"
moparisthebest
seems far simpler
moparisthebest
> so when a client logs in it has to check all pep nodes for all roster contacts all too I guess
lskdjfhas joined
pep.
A client doesn't "Check", notifications gets pushed to it, but sure
moparisthebest
even notifications sent before the client logs in?
equilhas joined
lskdjfhas joined
pep.
Sure, you say add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event✎
pep.
Sure, you add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event ✏
moparisthebest
if I understand it's just adding a bunch more login traffic, at least one extra outgoing stanza and an ack per contact?
moparisthebest
vs the key thing, which supports all the same use-cases, plus missing server, with no extra login traffic?
pep.
There's no extra login traffic if there's no event. And once you've seen the event on contactX, you can unsubscribe from it.
pep.
what key thing
moparisthebest
crypto signed "i've moved" roster subscription messages from the contact that moved
pep.
But then in my use-case you'd need an extra PEP node on your own account mapping old-jid -> new-jid of your contacts, so that all your devices can ACK.
pep.
Then you do that from MAM?
pep.
You can also use MAM without crypto. And that's how Ge0rG implements it for now in his draft
moparisthebest
isn't the roster stored on the server? can't only 1 client change it then?
moparisthebest
technically the server could change it and not involve clients
pep.
So what's your use-case then, do you want the server to be involved or not
moparisthebest
that server involvement would be optional, on the non-moving client's end?
moparisthebest
wouldn't need to be mentioned in the XEP, the server could just optionally do it instead of the client
pep.
That can be mentioned in the XEP yes, and we already had something like that in mind.
moparisthebest
I tend to think moved that doesn't support a server going away in the future wouldn't be very useful
pep.
I think it is
pep.
And that'd be my main use-case
moparisthebest
my point is that if you do it a slightly different way, it supports both use cases
pep.
"slightly" meaning crypto?
Steve Killehas left
pep.
:/
moparisthebest
sure
Steve Killehas left
moparisthebest
you aren't inventing primitives or anything scary, just signing a message and verifying a signature?
pep.
You don't need crypto for most of what you just said
pep.
If your use-case if "server going away in the future", you don't need crypto
pep.
As your identity provider is still alive
moparisthebest
ok let me clarify, I mean "I'm gonna go ahead and publish this now, and still want to be able to use it to move if my server goes away in the future"
lnjhas joined
Steve Killehas joined
pep.
publish where
moparisthebest
either signed presence like xep-27 or a PEP node?
pep.
Ok so what about non-supporting contact clients (which is a concerned that's been raised), at the time you published it, until you server went down
pep.
Also presence won't work, it's ephemeral
peterhas joined
moparisthebest
but you could save the key from the first presence you see or something, in your client
pep.
If you support it, sure
moparisthebest
non-supporting clients I think is the same regardless of method, if they don't advertise support, your client sends them a manual message?
pep.
And if you see it, in the first place
moparisthebest
(after it moves I mean)
pep.
Which is why I just don't want to worry about this use-case. With the current changes we have in moved, nothing prevents you to also publish your signed payload