...the moment you realize that you need to also add an <x/> element to MUC-PM delivery receipts.
bhaveshsguptahas left
jonas’
they *are* MUC-PMs
jonas’
I considered that obvious :)
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
actupperhas left
actupperhas joined
Danielhas left
Danielhas joined
Danielhas left
bhaveshsguptahas left
bhaveshsguptahas joined
Danielhas joined
Zashhas left
Zashhas joined
actupperhas left
actupperhas joined
jcbrandhas joined
actupperhas left
actupperhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
actupperhas left
actupperhas joined
bhaveshsguptahas joined
bhaveshsguptahas left
moparisthebesthas left
actupperhas left
actupperhas joined
wurstsalathas left
wurstsalathas joined
larmahas left
larmahas joined
actupperhas left
actupperhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
lksjdflksjdfhas joined
actupperhas left
actupperhas joined
actupperhas left
actupperhas joined
actupperhas left
jcbrandhas left
Alexhas left
moparisthebesthas joined
Alexhas joined
moparisthebesthas left
moparisthebesthas joined
gavhas joined
Alexhas left
Alexhas joined
Alexhas left
Alexhas joined
pep.
https://lab.louiz.org/poezio/slixmpp/blob/master/slixmpp/plugins/xep_0059/rsm.py#L28 why would amount default to 10? `max` in the XEP is not defaulting to anything is it?
pep.
I guess this specific implementation expects a value, because later on it does `self.query[self.interface]['rsm']['max'] = str(self.amount)`, and everybody knows that `str(None)` is of course `"None"`
madhur.garghas joined
linkmauvehas joined
moparisthebesthas left
moparisthebesthas joined
marc0s
just to confirm i'm not missing anything from reading '48, '60 and '163... there's no standardised way of storing/retrieving bookmarks individually instead of as a list of them, right? even when using pubsub you're expected to treat the list of bookmarks as a single item ("current"), or am i wrong?
Zash
Correct
Zash
But now, introducing Bookmarks 2: https://xmpp.org/extensions/xep-0402.html
marc0s
thanks Zash, I didn't thought it was really serious given that title, actually; will give it a read
Zash
But then you get the problem that you can only have one bookmark with older PEP implementations.
Zash
Probably want all these to just be backed by the same store serverside
Ge0rG
If only we didn't have to cope with legacy systems.
marc0s
i can consider myself lucky; it's for a custom implementation in a non-federated service so...
Kev
I think very often we don't, and our determination to make life hard for ourselves by doing so is a hindrance.
Ge0rG
Kev: it is a hindrance, but my gut feeling is that by breaking backward compatibility, we will drive ourselfs irrelevant even faster
Kev
Backwards compatibility is one thing.
Kev
We often try to ensure *forward* compatibility, and that's a world of pain.
Ge0rG
We often also overengineer our XEPs
Kev
I'm not sure to what extent that's true. We often try to make big generic solutions, and then years later find people are using them in interesting and unexpected ways. 60'd be a good example of a big complex thing that's seeing lots of use because of it's genericness (not in IM so much, but in other interesting systems).
Kev
In other times when we've tried to go for simple, pragmatic solutions to get things working, we've found dealing with the edge cases has been unpleasant (45, 308, etc.).
Kev
I guess protocol design is hard, maybe?
Ge0rG
0045 is not really simple, it comes with a huge number of unspecified corner cases.
MattJ
That's kinda what Kev said, right?
Ge0rG
I'd consider 0308 as almost elegant, except for three minor points: the number of old messages that may be corrected, the limitation to the full JID (that's gone now?), and the method to reference messages, which is a mess of its own and not the fault of 0308
Ge0rG
I'm saying that 0045 is the opposite of simple, pragmatic.
Ge0rG&
ajhas left
bent3nhas joined
bent3n
Hi I created openfire(v4.2.3) server on my virtual machine( ubuntu). When I tried using spark client 2.8.3 to login, I go this error '“certificate can’t be authenticated”. I got a similar error when I used pidgin. However, pidgin automatically corrected and I’m able to connect using pidgin. The thing is, I'm trying to connect using node-xmpp-client and I get this error: XMPP authentication error. What am I doing wrong ?
bent3n
jid: bent3n @localhost
bent3n
FQDN: localhost
bent3n
database: postgreSQL
bent3n
What am I doing wrong ?
lovetoxhas joined
Syndacehas left
Syndacehas joined
bent3nhas left
bhaveshsguptahas joined
moparisthebesthas left
bhaveshsguptahas left
bhaveshsguptahas joined
moparisthebesthas joined
bent3nhas joined
bhaveshsguptahas left
linkmauvehas left
linkmauvehas joined
bent3nhas left
moparisthebesthas left
bent3nhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
moparisthebesthas joined
bent3nhas left
bhaveshsguptahas joined
jonas’
tom, so, what I did for that weather stuff is that clients request weather forecasts as they need it.
jonas’
the XMPP <-> Weather API proxy caches and reacts to rate-limiting HTTP status codes appropriately.
jonas’
I didn’t do polling and then publishing into pubsub, because the clients are often idle for several hours, not needing any updates, so that would simply save resources on all ends of the equation
jonas’
Also, back when I started that project, I wasn’t comfortable with PubSub yet :)
tom
is that the only reason you didn't use pubsub? If you had to do it all over again would you?
Zash
Where did that come from? /me scans archives
Licaon_Kterhas joined
tom
I ask because meteorology is one of my interests
jonas’
Zash, operators@
jonas’
tom, I’m not sure, I think for the forecasts it doesn’t make sense to use PubSub still, at least not a normal PubSub service
tom
and I've done projects like that before, although my problems were more about getting the sensor data from the sensors to a server in zero-infrastructure areas
jonas’
if anything, the XMPP<->HTTP translator would have to be a PubSub service on its own
jonas’
so that clients can subscribe for updates based on their location
tom
I've been working on a dynamic self-healing mesh network
jonas’
publishing all weather forecasts for all possible locations doesn’t really make sense✎
jonas’
publishing all weather forecasts for all possible locations to pubsub doesn’t really make sense ✏
tom
but the thing is, I still need something to buffer the scientific data until the server can be reached to ingest it
tom
I'm thinking because of the reliable nature of XMPP, I could just use an XMPP library and send stanzas with it and have the library buffer those in case it can't reach the server
Licaon_Kterhas left
tom
and when it does flush the buffer
jonas’
> reliable nature of XMPP
jonas’
I think that is a dangerous statement unless you really know what you’re doing
tom
well what should I know?
jonas’
you need to know about stream management, and you should be using IQs for data transfer
jonas’
be able to deal with duplicate deliveries
jonas’
that’s probably already a good start
jonas’
and have a plan for when the server is longer unreachable than you can buffer
tom
that's what I'm talking about
jonas’
also, what you’re describing sounds like a Delay/Disruption Tolerant Network, which is an active field of research in the context of which I actually wrote my Masters thesis
tom
atmospheric conditions change and because the network is dynamic, node all nodes are reachable at all times
tom
another thing I was looking at was A.L.F.R.E.D.
tom
alright fact exchange daemon, but that's not really suited for distributing large facts
tom
and ounce a fact is distributed it overwrites previous facts
jonas’
tom, maybe have a look at the Bundle Protocol (RFC 5050) and implementations thereof
tom
even if I were to cryptographically sign my facts there's still a DOS vector
jonas’
(being a mostly academic thing for now to my knowledge, the tooling is rather rough at the edges)
tom
thanks, i'll look into that
tom
What I was thinking so far was to use a fault tolerant layer2 such as the batman advanced routing protocol along with IPv6 multicast groups for distribution and use unicast for re-trans in case a fact was missed due to temporary islanding.
tom
but using XMPP pubsub as a convenient way to access the data casually
tom
but going back to this, there are some interesting XEPs that can make XMPP a little more distributed network-wise
tom
like the server-less zeroconf XMPP configuration where as client can speak directly to each other
tom
zeroconf is an ugly protocol but it does work
tom
jonas’, Can I read your thesis?
tom
you got a website?
jonas’
I do, but the thesis isn’t on there
jonas’
which I probably should fix at some point
jonas’
I’m not sure whether it’ll be useful to you -- it is rather narrowly-focused on implementing a DTN gateway for a sepecific use-case.
jonas’
(it’s "just" a Masters after all, not a PhD)
jonas’
it’s not on my universities website, so I guess I have to check with them before sharing it
Lancehas joined
tom
you don't own the rights to your thesis?
jonas’
I do
jonas’
but that doesn’t mean I didn’t grant an exclusive right