rfc says https://tools.ietf.org/html/rfc6120#section-4.4 when closing a stream the side that closes has to wait for a closing in return
lovetox
but does that make sense in the case of a stream error?
lovetox
i get if i close the stream normally i want to give the other side the oppurtunity to send everything out it was going to send
lovetox
but in the case of a stream error, i will ignore anything anyway
paulhas joined
sonnyhas joined
asterixhas joined
kikuchiyohas joined
asterixhas left
asterixhas joined
lovetoxhas left
asterixhas left
asterixhas joined
sonnyhas left
MattJ
lovetox: if you'll ignore then yes. But does the RFC even allow clients to send stream errors?
Zashhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas joined
Meta Bergmanhas left
Meta Bergmanhas joined
Meta Bergmanhas left
Meta Bergmanhas joined
wurstsalathas joined
lovetoxhas joined
lovetox
yes MattJ why not
sonnyhas left
pulkomandyhas left
pulkomandyhas joined
kikuchiyohas left
pulkomandyhas left
Zashhas left
pulkomandyhas joined
Zashhas joined
kikuchiyohas joined
leosbrfhas joined
larmahas left
kikuchiyohas left
larmahas joined
Alexhas left
Alexhas joined
pulkomandyhas left
kikuchiyohas joined
pulkomandyhas joined
kikuchiyohas left
pulkomandyhas left
pulkomandyhas joined
sonnyhas joined
kikuchiyohas joined
asterixhas left
asterixhas joined
lovetoxhas left
lovetoxhas joined
debaclehas joined
sonnyhas left
kikuchiyohas left
flow
lovetox, why do you have to ignroe any inbound stanzas on stream errors?
Wojtekhas joined
lovetox
if i receive not well formed xml from the server
lovetox
and end the stream with a stream error
lovetox
why or how would it make sense to wait for more xml from the server?
lovetox
stream errors are not recoverable, means to me, all xml parsing ends right there
flow
ok, but thinking about the generic case, not the specific case where you can't recover from an ill formed xml stream
goffihas joined
flow
nothing forces you to not wait for the other side to close the stream and continue processing inbound stanzas
pulkomandyhas left
lovetox
nothing forces me, but then i would ignore the "unrecoverable" rule for stream errors
lovetox
as i would still wait and parse inbound stanzas even after an stream error
flow
I think the rule leaves room for interpretation
lovetox
that was not my question, if i *could* do it
lovetox
may question was does it make sense
lovetox
is there a case where i want data from the server even after he violated basic rules of a stream
flow
If you can process the data, then I don't see and advantage by not doing it
flow
*an advantage
pulkomandyhas joined
flow
If you can process the data, then I don't see an advantage by not doing it
flowhast to learn how poezio does autocorrect
lovetox
but there is no stream error other than malformed xml ones
lovetox
that client could send
lovetox
most stream errors are related to server actions
lovetox
like conflict, host-gone, not-authorized
lovetox
etc
lovetox
but yeah from the examples, i think its expected to send a close stream back even on error
lovetox
maybe malformed-xml is the exception where it really makes no sense
flow
What about errors on the layer above xml, like using XML mixed content, which is allowed by XML but disallowed in XMPP
pulkomandyhas left
pulkomandyhas joined
pep.
flow, /correct
flow
pep., and then I have to type the whole message again? Or is the idea that I select the message from the history, prefix it with '/correct', then correct it and hit enter?
how’s that different from send /stream, maybe receive stanzas, receive /stream?
Zash
you can maybe send sm:a?
jonas’
ah, that
jonas’
yeah
Zash
more roundtrips!
pulkomandyhas left
Zash
gotta add some after removing from the start
flow
Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if its worth it✎
Zash
probably not
flow
Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if it's worth it ✏
Zash
can get Close Enough ™ with unavailable presence I guess
flow
yeah, but nice to think about it
kikuchiyohas left
goffihas left
goffihas joined
pulkomandyhas joined
Link Mauvehas joined
kikuchiyohas joined
kikuchiyohas left
pulkomandyhas left
Syndacehas left
pulkomandyhas joined
Syndacehas joined
Kevhas joined
leosbrf
Hi all, when an user join a private room, I don't want him to have access to previous messages, only new messages. Is there a way I can accomplish that?
Zash
Yes, this can be implemented
Zash
Not aware of any publicly available such implementations tho
kikuchiyohas joined
leosbrf
Thank you, Zash. So I would have to write a module for this? I'm new to XMPP and currently I'm using ejabberd. Could you give me some references on how to get started on that?
leosbrf
links with docs or tutorials, besides ejabberd website itself, if any.
Zash
I can't do better than your favorite search engine I'm afraid
kikuchiyohas left
leosbrf
no problem, thanks anyway
kikuchiyohas joined
pulkomandyhas left
pulkomandyhas joined
kikuchiyohas left
flow
leosbrf, you may also want to ask this in the official ejabberd muc
pulkomandyhas left
sonnyhas left
pulkomandyhas joined
sonnyhas joined
debaclehas left
pulkomandyhas left
pulkomandyhas joined
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
pulkomandyhas left
pulkomandyhas joined
kikuchiyohas left
kikuchiyohas joined
asterixhas left
pulkomandyhas left
lovetoxhas left
pulkomandyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
lovetoxhas joined
pulkomandyhas left
wurstsalathas left
pulkomandyhas joined
asterixhas joined
wurstsalathas joined
debaclehas joined
pulkomandyhas left
asterixhas left
asterixhas joined
pulkomandyhas joined
asterixhas left
asterixhas joined
sonnyhas joined
lovetoxhas left
sonnyhas left
pulkomandyhas left
sonnyhas joined
lovetoxhas joined
sonnyhas left
pulkomandyhas joined
sonnyhas joined
asterixhas left
asterixhas joined
Wojtekhas left
pulkomandyhas left
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas joined
sonnyhas left
leosbrfhas left
asterixhas left
asterixhas joined
sonnyhas joined
asterixhas left
asterixhas joined
debaclehas left
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas left
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas joined
asterixhas left
asterixhas joined
sonnyhas left
asterixhas left
asterixhas joined
sonnyhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas left
strarhas left
strarhas joined
strarhas left
pulkomandyhas left
strarhas joined
strarhas left
strarhas joined
strarhas left
strarhas joined
strarhas left
strarhas joined
strarhas left
pulkomandyhas joined
debaclehas joined
sonnyhas joined
lovetoxhas left
lovetoxhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
marc0s
hi, is there some XEP or part of Core that defines capabilities for registered accounts? something like userA cannot make use of the MAM or Carbons, for instance? Something like different kind of accounts with different sets of permissions
Ge0rG
marc0s: that sounds like a policy configuration, not a protocol. What would you write down in the xep?
sonnyhas left
marc0s
Ge0rG, that sounds right, indeed. Maybe I'd like to have a way to query that policy. We've been asked for some weird (IMHO) requirement where some kind of accounts would only be allowed to receive messages, not sending them, but at the same time, senders should be aware of the recipient will not be able to answer because of that policy. I was just wondering if something already existed for that before inventing our own (basically doing that check out of band)
Ge0rG
marc0s: you might be able to appropriate https://xmpp.org/extensions/xep-0317.html (Hats) or https://xmpp.org/extensions/xep-0310.html Presence State Annotations
Ge0rG
but I'm sure there is no in-the-wild client support for either
marc0s
thanks Ge0rG. Client support is not an issue, we're rolling our own, based on stanzajs. Will have a look at that XEPs
lovetox
em, disco info comes to mind?
lovetox
but instead of routing it to the users, let the server answer with the caps for this account
lovetox
so a little server addon :)
moparisthebest
A: "can you send messages" B: "no but since I can't send messages I can't reply" A: *still waiting for response*
strarhas joined
pulkomandyhas left
marc0s
lovetox, yes, disco can be another way of solving this. Actually the XEP states than when querying a bare jid, it's the server who should answer, if I didn't misread it... so maybe yes, that's something a module can solve