-
lovetox
hm lib dev question
-
lovetox
if a lib has a JID object, and has a getBare() method
-
lovetox
what should it return if the jid is only a domain for example "asd.com"
-
lovetox
would be wrong to return asd.com
-
lovetox
should it raise an exception, NoBareJID or something?
-
Link Mauve
lovetox, why would it be wrong? asd.com is a valid bare JID.
-
lovetox
or is the localpart not mandatory on a bare jid
-
lovetox
ah ok nice
-
Link Mauve
asd.com/foo is a valid full JID.
-
lovetox
so barejid, is just without resource
-
Link Mauve
Yes.
-
lovetox
ah k thanks
-
jonas’
that ^
-
flow
lovetox, http://jxmpp.org/releases/0.7.0-alpha5/javadoc/org/jxmpp/jid/Jid.html https://github.com/igniterealtime/jxmpp#jxmpp-jid
-
lovetox
how likely is it that 2 different hash mechanisms produce the same hash
-
lovetox
like entity caps its mostly sha-1
-
lovetox
but theoretically you can also use something else
-
lovetox
right now i store the hash mechanism beside the hash
-
Link Mauve
lovetox, XEP-0390 fixed this issue AFAIK.
-
lovetox
but i wonder if i can just not store the hash mech
-
jonas’
lovetox, it is unlikely. but it’s stupid to not store the mechanism, too.
-
jonas’
it only costs a few bytes
-
Link Mauve
Can get down to a single byte if you convert the string into an enum.
-
Link Mauve
Assuming you know the mechanisms you can use.
-
jonas’
there was a thing...
-
lovetox
its not about storage cost
-
lovetox
i have a 115 cache
-
lovetox
which constists of hashmethod/hash -> discoinfo
-
lovetox
but then there are entitys we have to query and cache which provide no hash or have no presence at all
-
lovetox
like for example a muc
-
lovetox
i need to also store these disco info data
-
lovetox
but its hard to use the same cache
-
lovetox
because for muc i need a JID -> DiscoInfo kind of cache
-
lovetox
and that i need 2 different caches for discoinfo data .. somehow i dont like it
-
flow
but that's how it is
-
jonas’
lovetox, in aioxmpp, we listen on presence info and prime the JID -> DiscoInfo cache from the hash -> discoinfo cache
-
jonas’
that means that disco✎ -
flow
or, are you thinking about a generic String→ disco#info cache?
-
jonas’
that means that discoinfo lookups themselves only ever use the JID -> DiscoInfo cache ✏
-
flow
guess one could do that, but I'd personally wouldn't do so
-
jonas’
which is pre-populated on the fly by the entitycaps component which listens for presence
-
flow
especially since you could persist the caps cache to disk, while the jid→disco#info cache is somewhat unreliable and should have a sensible timeout (smack uses 24h)
-
lovetox
ah nice so when you need caps, you always access only the JID -> Disco info cache
-
lovetox
thats exactly what i was searching for
-
jonas’
lovetox, correct
-
lovetox
thanks
-
flow
jonas’, does that jid→disco#info cache only include values obtained via caps?
-
jonas’
flow, no
-
flow
or do you also put in results of actual disco#info requests?
-
jonas’
in fact, the jid->disco#info cache is in reality a JID -> Future(disco#info) cache
-
lovetox
yes thats the goal flow, often i have to disco info instances who dont have presence
-
lovetox
and i save that in a cache and store to disk
-
jonas’
lovetox, I’m not sure storing the jid->disco#info cache on disk is a good idea
-
flow
store to disk ephemeral data?
-
lovetox
for example a transport which im not subscribed to, if i load my roster i want to know the identity type so i can display icons that match
-
jonas’
that ^
-
jonas’
right, but treat it as stale and look it up at some point if you’ve loaded it from disk
-
lovetox
of course, you have have a last seen attr and perodically request again
-
jonas’
:+1:
-
lovetox
all disco info is stale the second you received it, so this has nothing to do with application restarts
-
jonas’
sure, but the longer you wait, the staler it gets :)
-
flow
plus with caps+presence you will get push notifications if disco#info changes
-
jonas’
flow, not for MUC services for example
-
flow
and can then react on that and invalide your cache etc
-
jonas’
which is what he’s talking about
-
lovetox
flow we are talking specially about entitys that have no presence
-
flow
I know. I just wanted to state that there is a difference between disco#info data with caps and that without
-
flow
for those cases like MUC, smack has a cache which expires its entries after 24h
-
flow
but actually, I am always pondering with that
-
flow
assume we one day live in a word where the xmpp service address will host most services (which I think is desireable for the services where it is possible). and your service operator updates the service, then you will potentially only become aware of that new feature after 24h
-
flow
stream:features to the rescue
-
jonas’
it’d be nice to have 115/390-like push for services, too
-
flow
wouldn't that be the case if you are subscribed to the presence?
-
lovetox
for muc this somewhat exists
-
flow
they just have to add xep115/390 metadata
-
lovetox
its called notification of configuration change
-
lovetox
i always disco after it
-
lovetox
because the notification does not tell you what changed
-
jonas’
flow, you’re assuming that all services expose presence
-
flow
so it is probably not a issue of a spec filling a hole, but implementations just doing that
-
flow
jonas’, well services need to know the subscriped entities to push 115/390 data to
-
jonas’
that is true
-
jonas’
I question whether that needs to be presence though
-
flow
and I think there is nothing wrong with just re-using presence for that?
-
flow
I can see the argumented of a polluted roster
-
jonas’
I think there’s some reason in not using presence for this at all
-
flow
but I wouldn't buy it
-
jonas’
that, too
-
jonas’
not for service-to-client, but for client-to-client presence, it quickly gets expensive to have all that stuff in the presence stanza
-
jonas’
so I wonder whether more fine-grained notification models wouldn’t make more sense
-
flow
hmm I'm sorry I can't follow, we where talking about services using caps to "push" diso#info to interested parties, and now you switch to c2s presences?
-
jonas’
flow, yes
-
jonas’
I’m questioning using presence for caps
-
jonas’
because presence is overloaded
-
jonas’
this is mostly relevant for c2s presences
-
jonas’
(or, more specifically, for client-to-client presences)
-
flow
so you basically want to re-open the old discussion between peter and phippo about presence floods? ;)
-
jonas’
maybe :)
-
flow
I mean clients do not change their disco#info feature often, do they?✎ -
jonas’
exactly
-
jonas’
that’s why *not* having this in presence would be good
-
flow
I mean clients do not change their disco#info often, do they? ✏
-
flow
please elaborate, because I think having a client specific caps in presence is potentially the only thing sensible in presence these days
-
jonas’
avatar hashes exist too
-
jonas’
GPG also
-
flow
well those should probably go in PEP
-
jonas’
exactly
-
flow
and openpgp is already in PEP
-
jonas’
I still see it in presence stanzas
-
flow
(if you use a modern XEP ;;)
-
jonas’
just like avatar hashes
-
jonas’
yeah, well
-
jonas’
the question is, if we’ve gone through the effort to move this rarely-changing data out of <presence/>, shouldn’t we also move that other rarely-changing data (ecaps) out of presence?
-
jonas’
what is the rationale for keeping it there?
-
flow
ok, so from a protocl PoV we are fine (at least in these areas), seems to be more of an implementation-is-missing issue
-
flow
jonas’, ahh, I was no thinking that the frequency of change should be a criterion here
-
flow
I was more thinking of "is this client specific" as criterion
-
jonas’
aha
-
flow
I don't think you want different avatars for different clients
-
jonas’
I was coming from the "rarely-changing data in a stanza which is often sent is a waste of bandwidth" angle
-
flow
(course, if you ask enough people, some people will say they want this…)
-
jonas’
yeah, the per-client-ness is an argument pro presence
-
jonas’
though we’ve already had enough arguments for the case that per-client caps are rarely useful and most of the time you’ll need something like an aggregated caps over all clients of the user (both min and max aggregates)
-
jonas’
and those caps could be distributed by the server in a non-presence vehicle and also contain full caps hashes for the individual clients which are currently online.
-
flow
yes, but, even if per-client caps are rarely useful, which I do not know if I would aggree, I do not see this as argument to remove them
-
flow
of course, what we have discussed regarding per-account caps appears still desireable
-
flow
and we should move towards that
-
jonas’
even if per-client caps are useful (which they sometimes are, I agree), the question is whether they belong in presence
-
flow
and maybe, just maybe, we will discovered that per client caps are no longer needed, but then they will probably vanish automatically
-
flow
yes, but I am not sure if this is the question we should answer right now
-
flow
it appears as something deeply baked into the core of xmpp
-
jonas’
not really, it’s in '115
-
jonas’
that’s not that deep
-
flow
and since they rarely change, i feel like it is not worth any effort getting rid of them
-
flow
but if you want to work on a spec which puts those into something else PEP, then please do✎ -
flow
but if you want to work on a spec which puts those into something else (PEP?), then please do ✏
-
jonas’
no, that they rarely change is a reason to move them out of presence
-
jonas’
if they changed "sometimes", presence would be a good place. if they changed "often", presence would be a terrible placce.
-
jonas’
if they change "rarely", they are dead weight in most of the presence broadcasts which happen
-
jonas’
(of course, if they change "often", they cause unnecessary presence broadcasts, which is arguably much worse)
-
jonas’
flow, yeah, I’ve been pondering that for '390, which is why I take the opportunity to discuss this
-
flow
ahh you not worried about caps triggering additonal presence broadcasts, but the mere existence of caps in every presence✎ -
flow
ahh you are not worried about caps triggering additonal presence broadcasts, but the mere existence of caps in every presence✎ ✏ -
flow
ahh you are not worried about caps triggering additional presence broadcasts, but the mere existence of caps in every presence ✏
-
jonas’
exactly
-
flow
tbh i never thought of this is something of a heavy burder✎ -
flow
tbh i never thought of this is something of a heavy burden ✏
-
jonas’
it gets heavier when you introduce hash agility (like '390) and modern hash functions
-
flow
I personally wouldn't invest time to improve here
-
jonas’
stuff gets more and longer
-
flow
true, but I do not think that we will change hashes often
-
jonas’
I’m not so sure of that
-
flow
sha1 has served us well for what? a decade or so?
-
jonas’
and even if we don’t change them *often*, the transition period may well be a decade of sending two hashes with each presence
-
jonas’
because oldstable
-
flow
obviously
-
flow
but if I had to guess i'd say we see 4-5 caps variants per presence at most
-
jonas’
which is quite a lot
-
flow
which surely is not optimal, but something I could sleep with
-
flow
jonas’, if you really want to reduce wire bytes invent an XML extension where the end element is always empty ;)
-
jonas’
ITYM EXI
-
Syndace
alright this is getting WAY to close to what we discussed for OMEMO just minutes ago, I have to jump in with something slightly off-topic
-
Syndace
We have the problem that for OMEMO, you subscribe to the PEP node of each of the contacts you want to encrypt with. And then we're flooded with PEP nodes on each connect, because PEP sends an update automatically on connect (right?). We were thinking about compressing stuff with EXI 😀✎ -
Syndace
We have the problem that for OMEMO, you subscribe to a PEP node of each of the contacts you want to encrypt with. And then we're flooded with PEP updates on each connect, because PEP sends an update automatically on connect (right?). We were thinking about compressing stuff with EXI 😀 ✏
-
jonas’
Syndace, EXI needs to be done on the stream level
-
flow
Syndace, a common pattern is to split PEP data into a hash and the actual data
-
jonas’
it would be cool if PEP services could do that
-
jonas’
that would solve the race condition issues around that
-
Syndace
Nah, EXI is just compression for XML, not talking about the EXI XEP but the EXI technology
-
flow
that way you only get the hashes on connect, which may already helps a lit
-
jonas’
Syndace, EXI generates binary output though, I’m not sure you lose 99% of the advantages if you have to wrap it in base64 again.
-
Syndace
Yeah that would actually help a lot
-
flow
not sure if this is possible in your case though, would need to have a closer look
-
jonas’
and if every client comes with an EXI implementation, we’re half way to being able to use EXI on c2s, which would be amazing
-
Syndace
Did a bit of research on available EXI implementations. It doesn't look super good but there are open implementations for C, Java, JavaScript and C#, though I can't say anything about the quality of those. Seem maintained at least.
-
jonas’
I hadn’t checked that far yet
-
jonas’
I only checked if libxml supports it (which it doesn’t)
-
flow
as much as like EXI, I am sceptic if this is the right solution to your problem
-
Syndace
flow I think that should be possible for OMEMO device lists, I'll mention it as a possible solution, thanks 🙂
-
Syndace
EXI could be used to compress bodies in general too, not only for the PEP node content
-
jonas’
we should really discuss letting PEP services hash the contents of nodes
-
Syndace
And we encrypt the bodies as binary data anyway (SCE), so we don't have to base64 stuff there
-
jonas’
but that’d require c14n, and nobody wants to go near that in XML :)
-
flow
Syndace, thay them the OpenPGP XEP said hello (that is where the idea came from)✎ -
jonas’
Syndace, yes
-
flow
Syndace, say them the OpenPGP XEP said hello (that is where the idea came from) ✏
-
Syndace
...should really read the openpgp xep again 😀
-
flow
jonas’> we should really discuss letting PEP services hash the contents of nodes +1
-
Syndace
yeah that would be awesome
-
flow
a generic optional mechanism where the push only contains "a hash" would be nice
-
flow
could potentially be as easy as s/+notify/+notify-hash/
-
flow
great, now I wanna write a new protoxep
-
flow
when I actually wanted to go into the hammock
-
Martin
You can't do both? Write in the hammock?
-
jonas’
flow, go ahead
-
Syndace
> could potentially be as easy as s/+notify/+notify-hash/ damn that sounds soo good
-
jonas’
+notify-hash-hash-hash-hash-hash-ha…
-
larma
flow, why not versioning instead of hash
-
larma
after all, a few hundred hash nodes that are the same as last connect also seeems kind of wasted...
-
jonas’
larma, what would the advantage be?
-
larma
jonas’, well if I have >100 contacts, each of them use(d) omemo,avatar,microblog,... and when connecting I +notify-hash, I still receive a few hundred hashes. And often enough those are just the same hash as last time I connected.
-
larma
With some versioning scheme it could be done such that I only get the changes since last connect
-
jonas’
larma, right
-
jonas’
I thought versioning per node
-
jonas’
where you wouldn’t win anything over hashes
-
jonas’
versioning per contact or globally (by your local server) would win of course
-
larma
true, yeah was considering global versioning
-
Syndace
+notify-hash-$LASTHASH
-
Syndace
😀
-
Zash
Uh, what have I missed here‽
-
jonas’
Syndace, you do realize that that immediately causes a loop? :)
-
jonas’
ah, no, not a loop
-
jonas’
but still terrible things™
-
Syndace
no I don't actually?
-
larma
Syndace, that wouldn't work because what would you hash, after all you receive multiple different nodes based on that notify
-
jonas’
Syndace, it’s part of your ecaps hash ;)
-
jonas’
it doesn’t cause a loop -- that was a mistake on my side -- but it still does fun things. since everytime you receive a pep update, your ecaps hash would change and you’d have to reemit presence
-
Syndace
oh right, you +notify for the node and not for each contact you want notifications from
-
Syndace
jonas' I wasn't thinking about updating the hash during runtime, just setting it to the last hash you saw before disconnecting last time. Only to avoid the one single automatic update that you receive on connect.
-
lovetox
hm are you aware that +notify✎ -
lovetox
hm are you aware that +notify-hash would change your disco info ✏
-
lovetox
just saying that would flood me with disco info requests everytime something changes in pep
-
lovetox
and this brings me to the topic that +notify is really bad in disco info
-
lovetox
i cant deactivate a feature without changing my disco info
-
lovetox
but on the other hand its really the most easy way to communicate to remote servers what you want hmm
-
Syndace
"hash" means the word "hash" here, not any actual value. so you'd put "+notify-hash" in disco info exactly the same way you put "+notify" there now. so no disco info change everytime something changes in pep.
-
lovetox
then i missed something
-
lovetox
how does the server know on what version i am?
-
Syndace
I don't think there even was consensus on doing versioning
-
Syndace
just a simple hash of the node content
-
Syndace
nothing more, nothing less
-
lovetox
where is the hash of the node contetn
-
lovetox
sent with the pep notification?
-
Zash
hash of what?
-
Syndace
hash of the pep node content
-
Zash
what normalization?
-
Zash
what c14n?
-
Syndace
whatever flow thinks of 😀
-
Syndace
> sent with the pep notification? yeah. instead of getting the content in the notification, you get a hash of the content.
-
lovetox
so instead of the actual data i get hundreds of pep notifications that contain a hash
-
Syndace
reduced bandwidth and if you need to know the actual content you can manually query
-
lovetox
and i have to query more if its not the hash that i have?
-
Syndace
yup, instead of 100 device lists, 100 hashes
-
Zash
Isn't something like this in XEP-0060?
-
lovetox
yes thats already in their
-
Syndace
(for example)
-
Zash
notifications without payloads at least
-
lovetox
its called omit the payload
-
Syndace
how does that work with the first update you get when you connect to the server and +notify?
-
lovetox
you get a notification just with the item-id without payload
-
lovetox
the item-id could be your version or hash
-
Zash
cf xep84
-
lovetox
but really thats not worth it for something like a device list on omemo
-
Zash
I've actually wondered why '84 doesn't just use payloadless notifications instead of a separate node
-
lovetox
the payload is small anyway
-
Syndace
lovetox well, the node can contain user-defined labels now
-
Syndace
so it can be a few times bigger than in legacy omemo
-
Syndace
for a few 100 contacts that adds up
-
Syndace
at least larma said that the device list notifications already make up a considerable portion of the traffic on connect
-
larma
It's probably not the only thing, but it's definitely visible
-
larma
haven't actually calculated how much bytes it makes
-
lovetox
you can reduce the payload
-
lovetox
but this does not change the fact that pubsub in its current form is just not scaleable
-
lovetox
it works nice until you reach X users in your roster
-
lovetox
then it becomes a burden
-
larma
you mean pep, not pubsub
-
lovetox
pep is a subset of pubsub
-
Syndace
payloadless notifications actually sound pretty cool, we'd have to set the item id to something with meaning though, like a hash of the content
-
Syndace
we use "current" at the moment
-
lovetox
then you need to configure the node to max-items=1
-
Syndace
and do payloadless notifications work with PEP notifications?
-
lovetox
which we sidestep with "current" right now
-
lovetox
Syndace, its a node configuration, and you can configure the default node just to enable it
-
lovetox
but this would probably break every client
-
Syndace
heh 😀
-
Syndace
sounds like something that might be a solution for OMEMO but I don't know enough about PEP/pubsub to push that idea forward
-
lovetox
what we really would need is a smart idea how we can avoid notifications all together if we already received it
-
lovetox
Syndace, you say solution like there is a problem
-
Zash
server-side device tracking?
-
Zash
pubsub-since?
-
lovetox
omemo and all other pep based xeps work fine
-
lovetox
its just not scaleable indefinitely
-
Zash
it doesn't have to tho, humans don't scale that well either
-
Syndace
"problem" is a strong word, but e.g. we don't put the ik into the device list because it's too big, so you have to query the bundle manually for every new device.
-
lovetox
openpgp puts the ik into the notification
-
Syndace
and if everybody sets a huge label for all of their devices, you'll notice the traffic probably
-
lovetox
so its not like it isnt already done
-
lovetox
if the payload gets to big, you do what the other xeps do
-
lovetox
add a metadata node
-
lovetox
that tells you only the current version
-
lovetox
see 0084
-
Syndace
isn't that exactly what the hash approach would do?
-
lovetox
yes, my example can be implemented and works tomorrow
-
lovetox
yours need support in X server implementations first
-
lovetox
and the result is the same, one is just more elegant
-
Syndace
I think we're drifting away
-
lovetox
why? its exactly what you want, you subscribe to a metdatanode, it always contains only the last hash or version
-
lovetox
and you define in the xep, if the version or hash is outdated, you request the payload node
-
Syndace
yeah sure, we talked about that for OMEMO
-
Syndace
I don't know why we're reiterating it now
-
lovetox
ok if im saying it now, i dont really see where the server could even help us here
-
Syndace
The server could create the hash for us on-the-fly, without the need for an extra metadata node
-
lovetox
but the extra node is on the server
-
lovetox
for the client nothing changes
-
Syndace
the client has to update the metadata node though
-
lovetox
he gets a notification with the hash, and requests afterwards a node
-
Syndace
when it publishes something
-
lovetox
yeah true it has to publish 2 things
-
lovetox
instead of one
-
lovetox
hardley worth a new xep and serverimpl though if you ask me :D
-
lovetox
its not like you publish daily devicelists
-
Syndace
if you do it manually, every XEP has to do it manually. If you can just subscribe to #notify-hash, every client can decide to do it without the XEP even mentioning the possibility
-
Syndace
> its not like you publish daily devicelists the problem is still the PEP update spam you get on connect
-
lovetox
yeah true, as i said its a bit more elegant
-
Syndace
yeah
-
lovetox
Syndace, you also get a pep update spam with notify-hash
-
Syndace
yes, but (in many cases) less :)
-
lovetox
yes as it would be if you use a metadata node :)
-
Syndace
less as in less bytes, not fewer updates
-
lovetox
but ok, if the server does it for us it indeed elegant for the client
-
Syndace
yeah. And it's easier than payloadless (is it?), because we can keep using one item with id "current" and don't have to rely on max-items (why not?).
-
lovetox
the problem with payloadless is its a configuration on the node
-
lovetox
so you have to get all servers to have this configured
-
lovetox
which does not make much sense in other cases
-
Zash
`pubsub#deliver_payloads`
-
Zash
Hm, I wondered why something wasn't (also) a subscription option. Maybe this was it.
-
Syndace
but the device list is its own node, isn't it? so you could just set that for the device list?
-
Zash
Did you not kill the 1+n node scheme?
-
lovetox
Syndace, node configuration is not nice with client
-
Syndace
we have two nodes, one with the device list and one with the bundles
-
lovetox
first you have to pull the node configuration, then you have to set a new one
-
lovetox
then you have to publish
-
Syndace
the bundles used to be split into n
-
lovetox
this is theroretically possible with publish_options, server support this only partly
-
Zash
single device id item or one per device?
-
Syndace
single
-
Syndace
two nodes in total
-
Zash
lovetox, easily solvable, just make the Conversations Compliance checker cry loudly about it
-
Syndace
ah items, yeah one item with the list
-
Zash
Hm
-
Syndace
lovetox we already require setting pubsub#max_items
-
Syndace
so might also require the other thing
-
Syndace
Zash, I think PEP only notifies about the newest item? That's why we want the whole list to be one item.
-
Zash
Another unshaved yak :/
-
lovetox
Syndace, max items is supported by publish options on most servers
-
Syndace
Why? 😀
-
lovetox
other node configurations are not
-
Zash
If you could somehow ensure that you get all of the items, it'd be cleaner
-
Syndace
(the Why was @Zash)
-
lovetox
but yeah if the option is not set, its not bad
-
lovetox
then you get the payload
-
Zash
And then you could use retractions to indicate device removal
-
Zash
Cleaner mapping
-
lovetox
retractions are not sent on coming online
-
lovetox
the one thing per item approach is good for stuff on your own server
-
Zash
https://xmpp.org/extensions/xep-0312.html uses relative time? 😱️
-
lovetox
like bookmarks, which you want to request anyway on every start
-
flow
Syndace, FYI https://wiki.xmpp.org/web/XEP-Remarks/XEP-0373:_OpenPGP_for_XMPP
-
flow
so yes pubsub#deliver_payloads would be the way to go, the wiki page has a note about that feature being not discoverable though
-
Syndace
cool! thanks for the link.
-
flow
I think I had the split metadata and data scheme in mind becaue that is what works with any minimal PEP implementation
-
Zash
Like 84?
-
flow
Zash, searching for devlier_payloads in 84 yields no results
-
Zash
it has split metadata and data tho
-
flow
and since I don't have any detail of every protocol in mind, I would appreciate what exactly
-
flow
aah ok
-
flow
I also lookinto into my notes and found a todo item regarding OK about deliver_payloads✎ -
flow
I also looked into into my notes and found a todo item regarding OK about deliver_payloads ✏
-
flow
Syndace> payloadless notifications actually sound pretty cool, we'd have to set the item id to something with meaning though, Do you really have to set the ID explicitly? Often it is enough to go with the pubsub service generated one
-
flow
soo good news, I don't have to write a protoxep, xmpp already provides what we need, we just have to implemented it in services and clients
-
flow
and I can go in my hammock
-
flow
Zash, actually I wonder if that split should be declared an anti pattern
-
lovetox
before you consider something an anti pattern you should at least provide a different approach to reach the same goal
-
Zash
flow: Mmmm, borderline. I personally think the (old) OMEMO thing with 1+n nodes was worse. But if it works, it gets deployed.
-
Syndace
flow actually there is a small but meaningful difference between +notify-hash and payloadless: payloadless has to be configured on the node while +notify-hash can be used on any node if the client wants to
-
Syndace
+notify-payloadless would be amazing too
-
Zash
You could invent that
-
Zash
Would be easier if it was implemented as a subscription option tho :/
-
Zash
and specced as one
-
Syndace
and payloadless should probably be made optional with a disco feature to reflect the current state of server implementations
-
Zash
Is there a feature for it?
-
Syndace
> the feature is not discoverable, most likely because it appears to be mandatory by XEP-0060
-
Syndace
from https://wiki.xmpp.org/web/XEP-Remarks/XEP-0373:_OpenPGP_for_XMPP
-
Zash
It there a feature for `pubsub#deliver_payloads` I mean
-
Syndace
if https://xmpp.org/registrar/disco-features.html is the list of features then no, can't find anything for "deliver_payloads"
-
Syndace
Anyway, the situation is quite clear, we can't rely on any of that for OMEMO. If we want to reduce the on-connect PEP update traffic, we have to manually specify some sort of metadata node.
-
Zash
Account level subscriptions + MAM? :)
-
Syndace
Any I think we agreed that it's not worth the effort given that the device list node is rather small generally
-
Syndace
I don't think a hard dependency on MAM is a good idea just for that
-
Syndace
how does account level subscription work? you subscribe using '60 instead of +notify and then you receive updates as messages that are stored in MAM while you're offline?
-
Zash
Syndace, you subscribe your account, notifications are sent there and could /in theory/ be forked (instead of the origin sending to each +notify) and MAM'd
-
Zash
In practice those notifications will just be discarded because type=headline
-
Syndace
ah, right
-
Zash
Could be solved by some future magic XEP probably
-
Zash
IM NG might help actually
-
Zash
Also possible to configure notifications to be sent as type=chat, but that's a node config, not subscription option :(
-
Syndace
meh
-
Zash
More of these fancy things as subscription options would be awesome
-
Zash
So each subscriber decides
-
flow
Syndace, yes, but do most xeps, including OMEMO not already specify how nodes should be configured? so I am not sure about how meaningful the difference is in this case
-
flow
I think we should probably tackle this from two angles: configuring the node to not deliver payloads *and* invent +notify-payloadless
-
larma
flow, how would you introduce +notify-payloadless to a federated network?
-
Zash
larma, haha .. :(
-
larma
well the problem is that it's not relying on your server to be updated, but on every server to be updated
-
Zash
larma, you do both +notify and +notify-payloadless and the receiver needs to ignore the former?
-
flow
larma, ^
-
larma
So as a client I get mixed responses, sometimes payloadless and soemtimes not?
-
larma
depending on what the other ends servers supported
-
flow
well ideally the node is also configured to no deliver payloads
-
flow
I actually think that this should be enough
-
Zash
Alternatively, mandate local server magic
-
Zash
Your server could easily hash the content (/me laughs in xml c14n) and forward you the hash
-
flow
Zash, I don't think c14n is relevant here
-
larma
If we do local server magic, I'd rather go full server magic and do global pep versioning
-
Zash
Oh
-
Zash
I'm confusing the hash stuff with the payloadless stuff
-
Zash
nm me
-
Zash
Should be trivial for a server to strip the payload
-
flow
even there, do not think of it as a hash, but an Abstract (PubSub) Node Data ID
-
flow
for which is true that if the node data changes that abstract id changes to
-
Zash
I thought I saw some talk about hashing the payload data somehow
-
flow
but it is not important that "similar" xml leads to the same id
-
flow
infact, if the data does not change, but there is a new id, that would be fine too
-
flow
one could even implement that abstract (PubSub) Node Data ID as counter
-
flow
i.e. it is the same id that xep395 would use
-
Zash
Anyways, a server seeing a pubsub notification that includes a payload, but the client has set +notify-payloadless then it should be easy to strip the payload and forward the rest
-
Zash
IIRC payloadless notifications still include the id, so if you stick a magic hash there you should be golden
-
flow
why is sticking a magic hash in there important?
-
flow
couldn't you just use the, you know, item id?
-
larma
flow, if item id is just 'current' all the time, that's not very helpful
-
flow
larma, it has not to be that way
-
flow
isn't current just because singleton node?✎ -
Zash
yes
-
flow
isn't 'current' just because singleton node? ✏
-
larma
yeah, but then taking a hash instead of a random number is a good idea, because changing back and forth will result in same id so no unnecessary requests for those that were not online in between
-
flow
now the question is if it is possible to keep the singleton semantic but have differnt IDs for different items, which seems desireable anyway
-
Zash
yes, but you need max_items
-
flow
larma, it is a good idea without doubt, but it is not strictly required
-
flow
Zash, and we do not have max_items? or is there no issue?
-
Zash
I think we do, but there's some extra care involved
-
Zash
Older prosody doesn't, but also doesn't support >1 items so it's fine.
-
flow
so, use max_items=1, delivery_payloads=false, service generated item id, → $$$
-
larma
can't we just build mam for pubsub instead, maybe using some shorthand +notify-archive which will cause the server to automatically subscribe to nodes and deliver updates from the archive when connecting?
-
Zash
🥇️
-
Zash
larma, any question including the word "just" automatically get "no" for an answer
-
Zash
It's never "just" anything :P
-
larma
😀
-
flow
life would be boring if things where that easy
-
larma
It's not about doing something that's easy
-
larma
It's rather about doing something that's meaningful
-
Zash
larma, pubsub+mam has been mentioned in the past as the glorious saviour of everything, but it's lacking in actual specification or somesuch
-
Zash
lacking in "how should it even work?"
-
Zash
I think MattJ had some stuff to say about it recently
-
larma
replacing `<item id='current'><devices><device id='1' /><device id='2' /></devices></item>` with `<item id='b5fec669aca110f1505934b1b08ce2351072d16b' />` isn't really a huge improvement IMO
-
Zash
How many phones and computers do normal people even have?
-
larma
Sure it's some improvement, but it still means O(n*m) traffic on connect (n = number of contacts, m = number of features that use pep)
-
larma
I alsways calculate with 3, but I feel it's probably rather 1.7 or something
-
larma
many don't even use their notebooks/desktops for messaging at all
-
Zash
I heard computer sales was picking up because everyone needed to work from home :)
-
larma
"I was sending SMS from my phone for the last 25 years, I'll continue to do so"
-
lovetox
thats what i said earlier, the whole idea makes it a bit more efficient, but in the whole great scheme of things, where everybody stuffs all into pep, it does not really matter
-
lovetox
but nevertheless it would be more elegant, and xeps would not need to define metadata nodes anymore
-
Zash
lovetox, have you heard of https://en.wikipedia.org/wiki/Jevons_paradox ? :)
-
lovetox
no i did not, but now i know
-
Syndace
should not forget in the size comparison that there are labels
-
Syndace
and clients will probably set default labels of a few chars
-
Zash
Labels?
-
Syndace
optional labels (=strings) for devices
-
Syndace
to make it easier to identify keys
-
Syndace
e.g. Gajim could set "Gajim on Windows" for its default label