-
lovetox
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
-
MattJ
lovetox: if you'll ignore then yes. But does the RFC even allow clients to send stream errors?
-
lovetox
yes MattJ why not
-
flow
lovetox, why do you have to ignroe any inbound stanzas on stream errors?
-
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
-
flow
nothing forces you to not wait for the other side to close the stream and continue processing inbound stanzas
-
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
-
flow
If you can process the data, then I don't see an advantage by not doing it
- flow hast 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
-
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?
-
pep.
/correct <tab>
-
pep.
Then you can edit and resend
-
pep.
But you can also /correct anothermessageinstead
-
flow
ahh✎ - flow
-
flow
ui ✏
-
pep.
And poezio doesn't yet implement the LMC "clarification"
-
flow
the "strike the last" from LMC?
-
pep.
no, the "always use the first id"
-
pep.
Otherwise yes in reading we do "Message Correction", not Last Message Correction.
-
pep.
We only send the last via /correct, but you can do /rawxml :x
-
lovetox
another problem, say i send close stream
-
lovetox
and the server answers with more stanzas because i let him like the XEP suggests
-
lovetox
i cant ack these messages anmore via streammanagement
-
lovetox
so the server will think i didnt get those messages
-
lovetox
..
-
MattJ
You can if you resume
-
lovetox
does close stream not mean i cant resume?
-
MattJ
Oh, right :)
-
MattJ
Yeah
-
lovetox
i think it causes more complexity and problems if after stream close, i wait for a stream close in return or any other stanza
-
lovetox
i dont see any benefit for client or server
-
jonas’
lovetox, the stanzas could still have been in flight
-
jonas’
if your link has latency
-
jonas’
you need some way to deal with this, even though "drop everything and log errors" may be a valid way
-
Zash
Resource-*un*-binding before /stream?
-
jonas’
you still have to deal with stanzas which are in-flight when you send your unbind
-
jonas’
same difference
-
Zash
send un-bind, maybe receive stanzas, receive unbind-ack, send /stream, receive /stream
-
jonas’
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!
-
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
-
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
-
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
-
leosbrf
no problem, thanks anyway
-
flow
leosbrf, you may also want to ask this in the official ejabberd muc
-
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?
-
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*
-
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
-
marc0s
moparisthebest, :D