Danielsonny, here is the stacktrace https://paste.rs/adf
Alexhas left
mikeyehas left
mikeyehas joined
Alexhas joined
machas left
Kevhas left
florettahas left
jubalhhas left
goffihas joined
Kevhas joined
belonghas left
sonnyHa it's a stream error, the server is closing the connection, not xmpp.js
sonnyApparently because the server is waiting on xmpp.js and it's not doing what it expects
sonnyCan you reproduce with passing --unhandled-rejections=strict to node?
sonnyAlso what server is that?
oibaloshas joined
Danielsonny, ok. nevermind then. but thanks for your help
i got tasked to code this by someone else who needed this. but they don’t know anything about xmpp but it also had to be node because node is all they use
Danieli originally just tried to point them to a 'good' javascript library. and then this grew into more and more me hacking something i don’t understand :-/
Danielso i'm not seeing this error. only they do. and apperantly they are seeing this only when thy try this from a server on the other side of world
Danielso i thought i'd just increase the client side timeout and be done with it
Danielbut now that it turns out to be something more weird i'm just gonna give up
sonnyAlright, please invite them to create an issue in the repository
marmistrzhas left
marmistrzhas joined
belonghas joined
marmistrzhas left
mikeyehas left
debaclehas joined
marmistrzhas joined
fade123has left
fade123has joined
FireFlyhas left
FireFlyhas joined
alacerhas left
debaclehas left
pasdesushihas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
marmistrzhas left
alacerhas joined
Wojtekhas joined
belonghas left
kikuchiyohas joined
mikeyehas joined
belonghas joined
pasdesushihas left
pasdesushihas joined
asterixhas left
asterixhas joined
lovetoxhas left
pasdesushihas left
mikeyehas left
lovetoxhas joined
pasdesushihas joined
marmistrzhas joined
florettahas joined
pasdesushihas left
fade123has left
fade123has joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
marmistrzhas left
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
belonghas left
tiaodhas left
belonghas joined
tiaodhas joined
machas joined
Wojtekhas left
Wojtekhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
Meta Bergmanhas joined
belonghas left
machas left
jubalhhas joined
jubalhhas left
Stefanhas left
cyrilhas joined
Stefanhas joined
cyrilHello, I am trying to use the slixmpp python library synchronously
cyrilLike
connect()
do_some_stuff()
close()
cyrilis there some examples using it like this ?
ZashI've no recent experience with slixmpp but I'd try prefixing every line with `await` and see what happens. :)
cyrilOh I was talking about sleekxmpp sorry
Stefanhas left
cyrilThe thing is that the code using the library is not aware of coroutines
Sam Whitedsleekxmpp is unmaintained and deprecated, if you're starting a new project in python I'd use slixmpp or aioxmpp
cyrilOk, I was talking of slixmpp, sorry 😅
cyrilThe interface exposed to client have to look like somehing synchronous
Sam WhitedMaybe just take the echobot example from the docs and remove the message processing and do whatever you want to do in session_start instead?
cyrilwith the event loop running in a thread
cyrilIt kind of work but outputs some errors when disconnecting, like "ERROR Task was destroyed but it is pending!"
cyrilI was thinking maybe someone has already done this
Sam Whited/cc mathieui (who mostly works on this, I think?)
cyrilOk thanks, might be the self.disconnect(wait=True) thing!
moparisthebestIt stopped working for me years ago and instead of wasting more time with python I just rewrote it in Rust, might help you as an example though
flowspeaking of, what is the go to rust xmpp library?
belonghas joined
jonas’Link Mauve, ^
Sam Whitedflow: https://crates.io/crates/tokio-xmpp
Wojtekhas left
Wojtekhas joined
flowthanks
Wojtekhas left
Wojtekhas joined
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
cyrilmathieui: Here is a minimal example of what I am trying to do https://pastebin.com/0VTQ7qtg
cyrilIf you have any insight
cyrilThat was for some quick unit tests, learning rust would be a bit overkill but it is on the todo list!
serge90has left
serge90has joined
pasdesushihas joined
edhelashas left
edhelashas joined
Martinhas left
Martinhas joined
pasdesushihas left
kikuchiyohas left
kikuchiyohas joined
mathieuicyril, I don’t have a lot of insight around using threads with asyncio, I know there are some barriers in place to prevent people from doing weird things
mathieuiyou should keep all slixmpp interactions in the same threads otherwise things can get weird pretty fast
cyrilok thanks
mathieuibut what you sent seems mostly correct, using process(forever=False) will run the event loop until the client gets disconnected
mathieuiwe might get rid of it at some point as it is confusing for people coming from slixmpp
cyrilactually it tells me « ValueError: loop argument must agree with Future » when calling process(forever=False)
cyrilwith the non minimal example it worked (with almost the same code…) but I got an error on disconnect
mathieuicyril, it looks like a future was created on another thread, which then used a different event loop
jubalhhas joined
mathieui(slixmpp tries to use one specific event loop and only one, but it will not help if things happen in a multithreaded environment)
tiaodhas left
cyrilyep, I will try again with everything in the same thread
cyrilthat was the plan anyway
southerntofuhey is this a good place to submit criticism of MIX spec? or should i wrote a mail/blogpost?
mathieuiFYI you can have something like
def func(self):
xmpp = ClientXMPP(…)
xmpp.connect()
xmpp.loop.run_until_complete(xmpp.wait_until('session_start'))
do_stuff() # you need to run the loop for most network operations though
loop.run_until_complete(xmpp.disconnect())
but it is not a very pleasant workflow
mathieuisoutherntofu, I guess an email to standards@ might be a more persistent venue for this?
southerntofuthanks, makes sense
tiaodhas joined
belonghas left
mathieuiI should finish the slixmpp implementation too, it is already working but lacks mix-admin or mix-misc
oibaloshas left
oibaloshas joined
southerntofuhmmm i see no intent (yet) to support in dino, gajim, conversations according to bugtracker
southerntofuis it because people are so happy with MUC? or because there's no momentum yet?
southerntofui'm asking because there's some privacy concerns i'd like to address with some MUCs (eg. occupant ID) and i was told MIX was probably the way to go for feedback on specs, instead of fixing/extending existing MUC XEPs
pep.honestly if you're waiting for MIX to fix this you're gonna wait for some more time
pep.There's two camps, choose yours :x
Sam WhitedI don't have any good reason, but I suspect it's a mix of MUC working "good enough" once the implementation is done (even though it's a mess under the hood), so there's no user pressure ot move, and MIX ending up being really complicated and requiring a lot of big dependencies (pubsub/pep).
southerntofupep., are you saying some people are not convinced by MIX and likely won't be?
pep.southerntofu, that
Sam WhitedSo you've got the double whammy of no user pressure and devs don't want to read 46 pages and implement a ton of new things.
southerntofuwell that makes sense Sam Whited
Sam WhitedThat being said, there is slow uptake. There are experimental implementations in a couple of servers and clients, at least.
southerntofuSam Whited, where can i see what clients/servers implement it?
southerntofumy 4 clients of choice apparently don't :P
moparisthebestsoutherntofu: it's just tigase
mathieuisoutherntofu, siskin is one
ZashITYM if you want MIX you should implement MIX
southerntofuZash, not sure i *want* mix, though building upon standardized building blocks for multi user chatting sounds appealing :)
Sam WhitedI think there were experimental implementations in ejabberd, prosody, and tigase (those devs will hopefully correct me if I'm wrong) and the tigase people had an implementation in their clients I think. Unsure if it's released or just on a branch somewhere though.
mathieuiBut yes, there is MUC which has worked well enough for years despite all of its warts, which we can mostly work around by now, and MIX which requires both pubsub support, multiple (albeit quite short) specs, and home server support
pep.And also has different trade-offs really
southerntofupep., what's the tradeoffs of MIX?
pep.Not saying I'm against MIX or pro-MUC, but they're not equivalent
mathieuipep., well, it is more modular and extensible, and the workflows aer nicer from a client dev perspective
mathieuithe main downside is the requirement of home server support
southerntofuand do you folks know if there's some people working on client/server test suite for MIX? soundsl ike it could help imlpmenetaiton
ZashWe could make it *drumroll* presence-based, like MUC, then you don't need home server support
mathieuiZash, please no
ZashIIRC there was brief discussion on some summit about that
southerntofumathieui, what do you mean home server? my understanding is if your server doesn't support it a MIX node can provide a MUC compatibility layer, correct?
mathieuisoutherntofu, it can be done, yes, but then from a client perspective you are not using MIX
mathieuipresence-based is my main peeve with 0045
southerntofuyeah i also dislike the whole "presence" concept (to me it's an antifeature though i understand in corporate settings i can be useful)
southerntofupresence-based chat sounds like IRC to me :)
Zashwhat
mathieuisoutherntofu, presence is a potential privacy leak but also useful information
mathieuiand MIX does not remove presence, it just removes it from the workflow and makes its support optional
southerntofumathieui, i don't have a use case for it, but i'm not opposed to people broadcasting presence info.. but in my view opt-in is better :)
ZashI can see how it was more useful back when you were online via dialup ~1h per day, but I don't see it as an anti-feature.
KevThe presence of presence isn’t an anti-feature, in my view, but tying MUC’s workings to it is.
Sam Whited⤴️
mathieui^
Wojtekhas left
ZashThis
Kev(Not because I don’t want presence in my rooms, I do, I just want it decoupled)
southerntofuZash, depends on the usecase, but it's a huge metadata leak (see discussion in #modernxmpp). i understand myhome server needs to know which clients are online to deliver messages, but i don't want anyone else to know about that, or whether i received a message or not
Sam WhitedIt's a metadata leak that won't matter for 99% of people though.
southerntofubut i can also understand people who want it
Zashsoutherntofu: Presence should definitely be protected, and XMPP tries to do that.
Sam WhitedIf you are that tiny percentage of people who need the absolute privacy you described, you need to be using a special service and clients and what not that are designed for that.
ZashWhy you need to add people and get their approval to see their presence
southerntofuZash, yes that's good, but that a MUC operator can see everyone's presence is a huge difference in the threat model (i.e. correlating identities) compared to simply subscription settings (at least when the convos are OMEMO-encrypted)
ZashYup. What Kev said.
southerntofuSam Whited, i don't understand your point.. should privacy just be for the 1%? i'm aware of the tradeoffs i make but most people are not..
moparisthebestdefine "privacy"
Sam Whitedsoutherntofu: no, but we don't need to optimize for the tiny percent of people who are worried about the threat you outlined. Most people it's perfectly fine if they join a MUC and share their presence.
Sam WhitedWe do a pretty good job of balancing that overall. Getting rid of all presence won't help the majority of people in any way, it will just annoy them.
KevI think it’s good to define protocols that can be used in a reasonably private manner.
mathieuisoutherntofu, I don’t see a thread model that has critical protection requirements on presence data (although sure, protecting it as much as we can should be a goal)
KevWhich MIX tries to do by allowing you to send or not send presence, but still participate in the chat, and it can be controlled on your server, so the room only needs to know when you send a message, or initially join.
KevCompared to MUC, where the MUC needs to know not only when you’re online, but how many (and which, practically) devices you have online at that moment.
mathieuiKev, with MIX, a client only needs to not send presence to the MIX items in their roster, right?
KevOTOH, I think Sam is right that 99% (or some high proportion of people) would choose to have the benefits of sharing presence with the room of their friends or whatever, over the privacy.
Kevmathieui: Yes, the client can just not set up presence and everything Should Just Work.
southerntofuKev, yes i think that's a huge improvement, however what started this discussion was in XEP 0403:
southerntofu> A MIX channel MAY require that all participants publish presence, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence.
KevPractically, the important bit there for privacy is ‘It is not possible to enforce this’ :)
southerntofumoparisthebest, defining "privacy" is a hard task.. there's different threat models, but i believe they should be more explicit in the specs :)
Sam WhitedTo repeat my argument from there: if you need that level of privacy, you can't rely on the server to enforce it anyways, so if you're writing a privacy aware client you'll need to show the user the room policy and not join the room if it requires presence.
southerntofuKev, well i'm ok with a server mandating its rules, but why would the spec say my client MUST send my data??
Kevsoutherntofu: We have the Security Considerations for that - but they’re only as good as the authors think of, and reviewers comment on.
Kevsoutherntofu: Yes, there’s room for improving that wording.
Sam WhitedThe client only MUST send the data if the room requires it. If the room doesn't require it (probably most rooms), you don't have to send the data. That's a pretty good privacy tradeoff.
southerntofuKev, wouldn't it be useful to have a dedicated mailing list / MUC to discuss privacy/security across the ecosystem and evaluate upcoming specs?
mathieuisoutherntofu, that’s supposed to be part of the global process
Sam WhitedYah, probably best to have them in public, no need for more low-traffic lists.
KevIt would be useful to have people reviewing privacy/security. That’s not quite the same thing :)
mathieuiKev, while you’re there, I’m unsure about the resource examples from mix participant jids in 0405
southerntofuKev, well i'm no expert at all, but i'm always happy to take some time to give a critical overview from an outsider's perspective (i don't have background on why all the technical decisions have been made)
KevThe upcoming specs all get sent out on the standards list where people can review and make such comments. Realistically the number of people reviewing upcoming specs is relatively low.
marmistrzhas joined
mathieuiare they supposed to mean something or to be public?
moparisthebestsoutherntofu, yea "impossible to define" because it means different things for different people is pretty much my point, I'm in private MUCs with my family hosted on the server in my closet, so presence is not a privacy problem at all (there)
moparisthebestspecs do have security concerns which is generally where privacy related stuff lives too I guess ?
Kevmathieui - can you give a bit of text for me to search on, or section number please?
mathieuiKev, e.g. https://xmpp.org/extensions/xep-0405.html#usecase-user-presence-receive
KevThe UUID-a1j/7533 bit?
mathieuiyes
mathieuiis it the resource of the client on the other side?
mathieuiand do we want to do resource leak in JID hidden channels?
southerntofumoparisthebest, that makes sense though i'm not the best person for formal processes :P
KevThis is the client’s resource, and it’s a long debate. We need unpredictable resources for a bunch of reasons. But at the Summit where we discussed this some people claimed that (despite XMPP already explicitly not guaranteeing your resource is the one you asked for) it was vital that they got the resource they asked for. So a two-part JID where the first half was server-provided, and the second half was client-provided was invented. It’s unrelated to MIX, it’s just the style that was used for those examples.
southerntofuso anyway thanks for all these answers i'll further read the spec and try to come up with a patch, maybe write for the "security considerations"
Sam WhitedI still *really* hate that. The only argument that I remember was that it was needed for logging, in which case it seems like your logging system should just be better and not force server changes that you can't guarantee anyways.
Sam WhitedRequiring a weird two-part JID just feels like solving the problem from the wrong end and asking for trouble when people inevitably start assuming that's always the format and splitting on the / or whatever. Then again, maybe there were other better reasons I'm forgetting.
KevI *do* think we want clients to be able to be uniquely identified by their own server, FWIW.
KevBut that’s not the same as saying it should be encoded in the resource.
moparisthebestthat's the thing that's optimizing for making it easier for human admins to scan XML streams and logs without server modifications right?
moparisthebestalways seemed beyond silly to me also
tiaodhas left
ZashThere's a disagreement on whether resources identify clients (ie are stable for the long term) or sessions (short lived).
mathieuiOk, thanks.
belonghas joined
mathieuiI’ll pretend that this is an opaque identifier
Sam Whitedremembers the horrors of HipChat encoding stuff in the resourcepart that the client and server both had to be able to parse
Sam Whited(not that that's what was happening with this split JID thing IIRC, but letting the client think it can guarantee anything being set is just too close for comfort)
Zashcontinues to ignore all the /Conversations.XXXX resources everywhere
Zashremembers Dino being upset if given a different resource than asked for (fixed now tho)
Sam Whitedjust ignores anything the client requests and gives them a random resource.
KevI think what people encode in resources is up to them in a closed system (or if they’re a server in an open system, for that matter).
KevI know GTalk used to encode cluster routing information into the resources, and that seemed fine (smart, even) to me.
KevWouldn’t work so well these days in the increasingly post-resource world, but back then it made sense.
Sam WhitedOh yah, HipChat did that too and that part was nice, it was the bits the client had to understand that made it a problem, made upgrades difficult, broke them if the server didn't have it for some reason, etc.
Sam WhitedBut yah, server sets the resource so if it wants to sneak some information in there it probably can't hurt anything.
Sam Whited(assuming it does like I said and doesn't accept the resource from the client, which could lead to issues if a malicious client tries to sneak stuff in)
raghavgururajanhas left
Yagizаhas left
debaclehas joined
pasdesushihas joined
flow> A MIX channel MAY require that all participants publish presence
how does a client discover this requirement? and how does a server know that a client complies?
Meta Bergmanhas left
flowmathieui> and do we want to do resource leak in JID hidden channels?
there is a resource like in MIX hidden channels? could you point me to it?
mathieuiflow, I was pointing out that MIX-Presence supposed that you keep the resource even in the "anonymized" JID you get from the service
mathieui
These JIDs will be used to represent specific JID clients. The resource associated with the encoded JID can be either of the follipwing two options:
The resource value from the associated client JID; or
A mapped valued to an anonymized value. This approach MUST be used with MIX-ANON.
mathieuinot a fan of the encoded JID thing, to be honest, but I can see how that is something you may want for plugging it into existing presence-handling code
Sam WhitedOh crap, when I thought that I didn't want to re-read thsi earlier and was complaining about the length I forgot there are actually 7 other XEPs some of which I'd need to also read in order to understand this. Yah, maybe I won't get to that this weekend.
Sam WhitedI guess technically it works with just core, so I'm going to pretend I didn't see that and try not to despair.
ZashSo summary XEP the broken down series is too long by itself?
flowto be fair, I believe groupchat protocols are simply not short
flowmathieui, which "encoded JID thing" exactly?
Sam WhitedYah, it's true, it is a *big* thing no matter how you slice it, but that doesn't make me feel better about the work I'd have to do to support it :)
flowhmm, if you have a decent PubSub/PEP support than creating a minimal MIX client implementation should be "easy". OTOH I did not do it yet in Smack, so I could be proven wrong.
flowhmm, if you have a decent PubSub/PEP support then creating a minimal MIX client implementation should be "easy". OTOH I did not do it yet in Smack, so I could be proven wrong.
mathieuiflow, user JIDs are "<opaque id>#room@service"
mathieuisee any example in mix-presence https://xmpp.org/extensions/xep-0403.html#usecase-presence-leave
flowmathieui, yeah right, you need to stuff the four-tule of (MIX service, room name, room-user id, and room-user session id) into a JID, which has at most three parts
flowI would have design it similar, so I don't see the issue with it
flow(I was considering adding the room-user id into the resource, but it appears all the same in the end)
flow*four-tuple
Sam WhitedGuess I'll have to read pubsub (20 pages) and its smaller and simpler cousine because pubsub was too complex, pep (25 pages) as well. (not that I think mix would have been better of without using existing building blocks, I just don't think it's feasable for me to actually implement all of this any time soon)
raghavgururajanhas joined
Zash20 pages?
flowSam Whited, you have to look at it this way: MIX motivates you to implement PubSub, then PEP, and with that you have the building block for another dozens XEPs like bookmarks, avatars, …
Sam Whitedish. I know it's not a great measurement, half of that is probably just version and appendices
ZashHow are you measuring?
Sam Whitedprinted to PDF
ZashDid you forget a zero?
flowhe didn't specify the paper format
flowfor all we know, it could be A2
ZashThe PDF version of 0060 is 182 pages, PEP is 19
Zashor is this about one of the MIX XEPs?
Sam Whitedhuh, that would make more sense, let's see what this did weird
flowWhile cool kids have posters of their favorite swedish speed-death metal band on their wall, flow likes to look at walls full of specifications to read
Sam WhitedPEP is 20 for me (I was looking at the wrong one) but XEP-0060 appears to have printed (in that the first/last pages are correct), and it's also roughly 20, weird
Sam WhitedI did think it would be a lot longer thoug, so that's weird
ZashSurely you mean 20 *stacks* of paper?
edhelasstill shorter than LOTR
ZashWe should resume the cut&paste we started in ... like 2014?
flowZash, IIRC it was 2015
Sam Whitedoh yah, there it goes, now it's 223 pages. No idea what happened last time or how it left pages out of the middle.
jubalhhas left
flowThe main problem you want to avoid with large specs like PubSub and MIX is unclarity about the required and optional parts. Ideally a XEP tells you early about the required parts and extension points for optional features, so that a developer can stop reading after them when starting an implementation. I think PubSub fails to do so.
Sam WhitedYah, I tend to agree
Sam WhitedI was having a discussion with someone earlier who was saying they hoped the last holdouts from XMPP would switch over to working on / using Matrix, and while I pushed back against that for all the usual reasons, one of the things someone else said was that the Matrix specs were just a lot clearer and easier to build on top of even if you already started with a basic protocol implementation and were just developing features. I don't know if they had pubsub in mind when they said that, but I do suspec they're not wrong when I look at things like this.
Sam WhitedI don't really know how to improve that situation though, unfortunately.
KevMatrix is a chat system though, isn’t it?
ZashIt's a distributed JSON graph database.
Sam WhitedIt's a protocol that's used for a lot of things in the same way XMPP is.
Sam WhitedBut mostly for a chat system.
ZashIt does get further with "simple clients, complex servers" than current XMPP does, I'll give them that.
Sam WhitedAmusingly, this discussion took place over IRC.
Sam Whited(for me, I assume they were on Matrix)
asterixhas left
asterixhas joined
fade123has left
jubalhhas joined
flowI find the Matrix specifications on https://matrix.org/docs/spec/ heavily API centric, I am missing a description of their basic principles
mathieuiflow, that was also my conclusion a few years ago, this is an API documentation at most (maybe that got better even if it is not what you would like, I don’t know)
flowI just skimmed over it, it appears to be a bit better now
ZashJSON Web API all the things.
floweventually I always wondered if that "distributed graph" thing matrix does could also be done on top of XMPP, I see no reason why not
ZashSure you can
raghavgururajanhas left
flowthat would allow you to exploit an existing federated network, but HTTP and JSON where probably to tempting to use
Sam WhitedSure, but if we write another 200 page spec to do it and mock them for using json instead of getting our own house in order it's probably not going to be very helpful.
flowmocking them for using json is not helpful, right
flowbut writing and implementing a spec similar to matrix's distributed graph thingy should be fine
Zashflow: you thinking MAM replication instead of routing, or something?
flowright, but then again, I am fine with centralized room management
flownot sure if we need to have something that provides eventual consistency
raghavgururajanhas joined
flowthere are surely distributed systems where you want to have eventual consistency, but can't think of a reason why federated groupchats should be based on such a system
flowif you want availability, use an server implementation that supports clustering
flowI'd love to hear the take on a Matrix person on that
mathieuiflow, I don’t really have much insight over how matrix works, I assume the replication & eventual consistency allow a more "resilient" view over rooms, without additional requirements for the server "hosting" the room for real
Zashthey usually compare it to git
mathieuiYou can probably interact with the people on your own server who are also in that room, and that counts as delayed writes when the "real" room gets back online
mathieuiI mean, that is an interesting property to have, against outages, censorship, etc
mathieui(I am only speculating obviously, I don’t know if that is even possible, as reconciliation between all of that state must be a real pain in the neck)
flowmathieui, use a high-availability cluster to reduce outages, planed maintainance is usually not an issue, not sure how it helps against censorship
Zashflow: you can remove a server and the room lives on on other servers
mathieuiflow, in the event of a server being bleeped out of existence by a powerful actor, instead of a whole lot of nothing, you have split communities across the ecosystem
flowalso, what incentivies servers to keep state of rooms the don't "own"
Zashflow: now that's a question
Zashand how do you enforce moderation, bans etc?
flowpotentially someone will answer, "no server owns a room", but the question still applies
mathieuiflow, well for matrix, "because that’s the protocol", but otherwise, I don’t know
southerntofuflow, my understanding of the matrix model is censorship-resilience.. if my server with high availability gets seized/disconnected/attacked other people can continue chatting as if nothing happened.. it's not in my threat model, but i understand the value of it eg. for a wikileaks chan :)
Zashblockchain? probably blockchain.
southerntofu(ah people just said the same sorry i was reading backlog)
flowsoutherntofu, sure that is a very nice property in theory. but doesn't that somehow imply that all servers need to keep all the state for eternity?
mathieui(and if that is a desired property, then you need to put it in the base protocol to have the incentive "this must work")
flownotsurehowthiscouldscale
ZashI tried reading the s2s spec once and it gave me a headache. Quite the opposite of XMPP s2s where you just open a stream and send stuff.
southerntofuflow, not necessary for all eternity, but sure that's the main problem with matrix servers lol
Danielhas left
mathieuiI don’t want to try to read the specs again, but I imagine you must have the latest state to be able to send writes to the upstream server
southerntofui mean i understand why you would support this use case in some circumstances, but making it the default takes hardware requirements through the roof
mathieuiwhich require you to effectively maintain the state internally
flowmathieui, I don't think this is true
flowif it is a dag, then you just need to have some dag node
flowand eventually someone will reconcile
flowbut you should be able to write without having the latest state, I mean that is the core of eventual consistency
southerntofuflow, though another interesting property is because so many beefy servers store the state, you can host your server on a very unstable uplink that often gets disconnected from the internet, without resulting in eg. netsplits alla IRC :)
mathieuiI don’t know how the state is managed and what is accepted and what isn’t so I will not try to extrapolate further
flowsoutherntofu, that's actually a very good point
flowXMPP links are very fragile if the reciving end is on a low-bandwith connection
flowXMPP links are very fragile if the receiving end is on a low-bandwith connection
flowIMHO one of XMPPs biggest weakness
flowOTOH, MIX/MAM mitigates this (a bit)
southerntofuflow, yes that's why FMUC was so interesting, though i still have to finish reading MIX spec because they said there was something equivalent :)
ZashStill tricky with s2s outages
flowZash, right
flowI think if I where to do XMPP again, I would base it on pulling, not pushing
flowbecause with pulling, the receiver can determine the rate
etadrops https://theta.eu.org/2019/10/10/nea-federation-design.html in here
jubalhhas left
southerntofuflow, doesn't PubSub support pull modes?
flowsoutherntofu, sure it does
flowbut I was talking about pulling a first-class principle
ZashThis reminds me, has anyone looked at MLS? I read the architecture doc and it talked about requiring guaranteed eventual delivery.
flowe.g. sending a message is just putting the message into your server's archive, the server informs the recipient about the new message. once the recipients server has pulled the message, the "pending messages" flag is cleared
southerntofuflow, isn't that what happens already when an s2s message can't be delivered?
southerntofuisn't there like MAM for s2s? :P
Zashsoutherntofu: there is not
southerntofuoooh, my bad for assuming otherwise :)
flowsoutherntofu, not exactly, and even if, not potentially
southerntofusounds like it could be useful
ZashMAM for s2s would pretty much be the "matrix over xmpp" flow mentioned earlier
southerntofuwell matrix over XMPP would be that + guaranteeing eventual consistency between several nodes who all act as authority for a resources (which is way more comlpex)
flowIsn't "MAM for s2s" a little bit to vague? Hmm, but yes, if it is vague, then it could be pretty much everything ;)
Zashflow: You could also figure out s2s+198 with resumption.
ZashNot graph stuff tho
flowZash, sure, but what I have in mind is much more radical
Zashflow: wanna write a xep about `<previous id="mam id of previous message"/>` and how to use that to magic together archives?
southerntofueta, i love your article (not finished reading just yet), the "sponsoring servers" is precisely what MX/NS secondary servers are about :P
flowZash, once I get a better grasp about where this is exaclty going, why not. :)
flowuh, and I would need to fall into a pot of gold first, so that I can take the required time to do so :)
Zashflow: Lets you detect holes in archives at least, if you receive a message with a pointer to a previous message you don't have. Throw some graph theory at it and call it Matrix over XMPP.
flowhmm, having an extension that points to the preceeding message in <{mam:2}result/> actually does not sound like a bad idea
flowwe don't we have that already?
southerntofueta, https://xmpp.org/extensions/xep-0289.html sounds a lot like what you're talking about (federated MUC) :)
Zashflow: not unless you count rsm, but it's not excatly that
flowthinking about it <{mam:2}fin/> is probably the better place
Zashflow: I was thinking about this for live messages
ZashFor patching up after s2s outages
ZashRemember how MIX and s2s outages is an unsolved problem :)
etasoutherntofu: indeed!
etashame nothing implements it though
Zasheta: you don't happen to have markdown sources for that blog somewhere? I like to convert to .epub for reading and source files tend to be less messy than converting from html.
KevZash: Undocumented solution, but I’m sure I discussed how to address it at the summit last year or the year before. Indeed, just by signalling there’s a hole.
southerntofueta, it doesn't look over complicated to implement.. also i need to finished reading MIX spec but it looks like there's some stuff about that in there too :)
fade123has joined
pasdesushihas left
oibaloshas left
oibaloshas joined
asterixhas left
asterixhas joined
lovetox_has joined
etahas left
etahas joined
etahas left
jubalhhas joined
etahas joined
asterixhas left
asterixhas joined
marmistrzhas left
goffihas left
goffihas joined
marmistrzhas joined
jubalhhas left
stpeterhas joined
kikuchiyohas left
mikeyehas joined
Ge0rGhas left
marmistrzhas left
Ge0rGhas joined
Ge0rGhas left
Ge0rGhas joined
raghavgururajanhas left
jubalhhas joined
jubalhhas left
oibaloshas left
oibaloshas joined
friendlyOtterhas joined
friendlyOtterOn xmpp.org they mention stroke as client library. A quick look around in the java world and i found camel-quarkus-xmpp. Any advice/remarks on that one?
Sam WhitedI haven't used it, but that looks like it's just a simple thing to get XMPP messages into/out of their integration framework, not a full XMPP library?
Sam WhitedThere's also babbler if you're just looking for something in Java: https://bitbucket.org/sco0ter/babbler/src