Logs for jdev

Show join/part/nick changes:

[00:24:06] * Lance left the chat.
[00:35:58] * psa joined the chat.
[00:49:34] * psa left the chat.
[01:12:23] * Lance joined the chat.
[01:15:02] * darkrain_ left the chat.
[01:39:12] * Neustradamus left the chat.
[01:51:56] * darkrain joined the chat.
[02:14:20] * Tobias_ joined the chat.
[02:19:45] * Tobias left the chat.
[03:31:45] * Lance left the chat.
[03:43:22] * Lance joined the chat.
[04:04:11] * Lance left the chat.
[05:12:19] * Asterix joined the chat.
[05:14:09] * vorner joined the chat.
[05:32:36] * Asterix left the chat.
[05:49:32] * vorner left the chat.
[05:57:18] * Tobias_ left the chat.
[06:04:24] * bear left the chat.
[06:14:17] * Zash joined the chat.
[06:30:48] * Alex joined the chat.
[06:35:21] * ermine joined the chat.
[07:40:20] * spencer.macdonald joined the chat.
[07:40:24] * spencer.macdonald left the chat.
[07:41:42] * spencer.macdonald joined the chat.
[07:41:56] * Zash left the chat.
[07:44:13] * mody joined the chat.
[07:49:10] * mody left the chat.
[08:09:40] * Beanow_ joined the chat.
[08:09:45] * Zash joined the chat.
[08:18:51] * Beanow_ left the chat.
[08:34:47] * whatever joined the chat.
[08:41:58] * Philonous joined the chat.
[09:09:27] * jcea joined the chat.
[09:43:06] * Guus joined the chat.
[09:45:27] * Zash left the chat.
[10:00:46] * Zash joined the chat.
[10:00:55] * Zash left the chat.
[10:00:58] * Zash joined the chat.
[10:18:44] * akuckartz joined the chat.
[10:18:55] * MattJ joined the chat.
[10:21:47] <MattJ> spencer.macdonald, maybe you see now why read receipts haven't been standardized so far :)
[10:22:30] <spencer.macdonald> :)
[10:22:33] <MattJ> I think each message should present a question to the recipient, which they must answer correctly to prove they've read the message
[10:22:58] * spencer.macdonald left the chat.
[10:23:55] <Zash> I say, guesstimate from chat states and be done with it.
[10:24:20] <MattJ> Doesn't work if you're offline when they read it
[10:24:32] <MattJ> and then you come online later when they are offline
[10:25:50] <Zash> So ignore the bits of the specs about stopping when someone goes offline
[10:26:06] <Zash> and ignore the bits of carbons and mam that tell you to skip messages without body
[10:26:24] <MattJ> and save chatstates as offline messages?
[10:26:28] <Zash> yes
[10:26:33] <MattJ> That's an awful lot of spec ignoring to do :)
[10:27:00] <MattJ> Might work in a closed system
[10:27:05] <Kev> My approach to read receipts was going to be simply 184 with a different payload name, and saying "Require the user to ack each message manually".
[10:27:24] <Kev> I've had it on my TODO to write such a thing for ages, but for some reason I keep finding myself busy.
[10:27:39] <MattJ> Yes, same protocol was in my mind
[10:27:40] <Zash> But I doubt most people outside of the military really want that.
[10:28:01] <Kev> Zash: indeed, and for those people we can do 'well enough' with what we already have.
[10:28:03] <Zash> I for one doesn't want to click any more buttons
[10:28:21] <MattJ> Good thing you have a choice of clients :)
[10:28:22] <Kev> 184+<active/> is probably sufficient for most cases.
[10:28:31] <Zash> Yes
[10:28:45] <Kev> And while there are edge cases, like you going offline, they're mostly edge cases.
[10:30:01] * akuckartz left the chat.
[10:30:23] <Kev> The local-unread problem is much more interesting.
[10:30:43] <Kev> "Which messages have /I/ not read yet?"
[10:31:12] <Kev> And yes, for that you end up needing markers back into MAM, and using carbons, if you want to get it perfect.
[10:31:37] <Kev> Although http://doomsong.co.uk/extensions/render/multiple-clients.html is a reasonable approximation.
[10:34:09] <Zash> I was thinking PEP
[10:34:31] <Zash> Since you only need a pointer to a MAM id
[10:34:44] <Zash> But that needs PEP
[10:34:47] * spencer.macdonald joined the chat.
[10:34:47] * spencer.macdonald left the chat.
[10:34:47] * spencer.macdonald joined the chat.
[10:34:48] * spencer.macdonald left the chat.
[10:36:25] * spencer.macdonald joined the chat.
[10:37:33] <Kev> I quite like the simple 'have I replied to it?' heuristic.
[10:47:01] <dwd> Funnily enough, it's the edge cases which interest me most for 1:1 chats. For MUC, however, it's much more interesting - the thing Hangouts is doing seems quite sensible in terms of UI, and it's something we can't currently do in XMPP.
[10:48:49] <Zash> dwd: What and why?
[10:49:31] <dwd> 1) I'm interested in the edge cases because it's quite often "Did he see that before he went?".
[10:50:18] <dwd> 2) The Hangouts thing is that you can see what each occupant in their MUC equivalent has read so far. Think in terms of the Gajim "Line Of Attention"™, except shared to all participants.
[10:50:37] * spencer.macdonald left the chat.
[10:50:40] * spencer.macdonald joined the chat.
[10:50:41] * spencer.macdonald left the chat.
[10:50:44] <Zash> The how-far-have-they-read thing, why can't it be done with chat states?
[10:51:04] * spencer.macdonald joined the chat.
[10:51:04] * spencer.macdonald left the chat.
[10:51:42] <dwd> Zash, In MUC?
[10:51:55] <Zash> dwd: Yes?
[10:52:16] <dwd> That would imply doing chat states over MUC, which we currently don't.
[10:52:28] <Zash> We do :/
[10:52:36] * spencer.macdonald joined the chat.
[10:52:36] <Zash> For some set called "we"
[10:53:20] <Zash> Which includes poezio and MattJs web chat thingy
[10:53:55] <dwd> Oh, indeed. FOr some reason I thought it was a no-no.
[10:54:17] <dwd> But I see §5.5 actually defines it. Interesting.
[10:56:48] <Zash> I'd like the MUC to be aware of it and possibly do something intelligent with them, like not cluttering history.
[11:23:33] * Schnouki joined the chat.
[11:24:01] * Schnouki left the chat.
[11:24:18] * Schnouki joined the chat.
[11:24:39] * Tobias joined the chat.
[11:33:36] * spencer.macdonald left the chat.
[11:40:00] * Kev joined the chat.
[11:56:26] * Guus joined the chat.
[11:59:43] * scippio joined the chat.
[12:51:10] * naw joined the chat.
[12:56:55] * xnyhps joined the chat.
[13:00:42] * ThurahT joined the chat.
[13:04:01] * Zash joined the chat.
[13:20:20] * ermine joined the chat.
[13:38:52] * naw left the chat.
[13:53:26] * Guus left the chat.
[13:56:12] * Tobias joined the chat.
[14:06:19] * Asterix joined the chat.
[14:10:08] * Zash left the chat.
[14:17:51] * hawke joined the chat.
[14:20:45] * dwd joined the chat.
[14:29:15] * jcea joined the chat.
[14:35:20] * vorner joined the chat.
[14:43:23] * pidgin joined the chat.
[14:43:28] * spencer.macdonald joined the chat.
[14:43:45] * Zash joined the chat.
[14:43:45] * pidgin left the chat.
[14:45:06] * darkrain_ joined the chat.
[15:24:31] * Schnouki joined the chat.
[15:26:31] * Zash_ joined the chat.
[15:28:26] * Zash left the chat.
[15:36:21] * vorner left the chat.
[16:01:48] * deryni joined the chat.
[16:13:30] * Zash_ left the chat.
[16:23:25] * Lance joined the chat.
[16:32:52] * StackOverflow joined the chat.
[16:41:38] * spencer.macdonald left the chat.
[16:49:47] * Zash joined the chat.
[17:09:52] * Schnouki left the chat.
[17:18:52] * bear joined the chat.
[17:27:29] * psa joined the chat.
[17:34:03] * psa left the chat.
[17:34:23] * psa joined the chat.
[17:36:03] * Guus joined the chat.
[17:51:41] <ermine> psa: hi, i have stupid question on rfc6120
[17:53:02] <ermine> does rfc6120 allow or not sending elements with namespaces different from feature or stream namespace, during feature negotation?
[17:53:22] <psa> hi ermine
[17:53:46] * jcea left the chat.
[17:55:06] <psa> ermine: in general, a client isn't allowed to send outbound stanzas until after it has authenticated, but maybe your question is slightly different
[17:56:27] <ermine> yeah, it is clear about clients
[17:57:19] * Tobias left the chat.
[17:58:20] <ermine> psa: should client expect something unexpected from server?
[17:58:59] <ermine> psa: most implementations dont expect
[18:02:00] * 0xAFFE joined the chat.
[18:06:52] * Neustradamus joined the chat.
[18:08:12] <dwd> ermine, So my reading is that servers only send the <stream/> open tag, followed by the <features/> element, which may itself contain other elements (embodying features) which are in namespaces unknown to the client.
[18:08:57] <dwd> ermine, But that's it - no other top-level elements before negotiation, because otherwise a client wouldn't be able to know if they were critical extensions or not. (to borrow a term from the directory world).
[18:16:56] <ermine> i mean during one (any) feature negotation, inside negotation or how it is in english
[18:17:38] <Zash> You can invent your own feature if you like
[18:17:50] <ermine> for example, suppose, server send you iq:version request when you wanna starttls negotation
[18:17:52] <dwd> I mean a server can send <stream><feature><unknown-stuff/></feature>
[18:18:47] <dwd> But it cannot send <stream><feature><unkown-stuff/></feature><other-unknown-top-element/> to a client, because no negotiation for that feature has happened.
[18:19:51] <Zash> ermine: I wouldn't count on such things working with all clients.
[18:20:50] <dwd> ermine, Oh. No, things like version requests aren't very likely to work until a session is bound. (ie, has done resource binding).
[18:21:24] <dwd> ermine, What I'd suggest is that you do such things when a client sends initial presence, but you (the server) hold their presence in abeyence until you've done testing the client.
[18:22:42] <ermine> dwd: does rfc6120 prevent your server from sending iq:version or you wanna rely on good sense?
[18:24:04] <ermine> in fact i want simplify flow process with stream features in client and always be sure in xmpp safety
[18:25:35] * jmedev joined the chat.
[18:25:54] <dwd> ermine, It doesn't, I think - however, I also think it prevents the client from responding...
[18:26:18] <dwd> ermine, You're going to make me look, aren't you? :-)
[18:26:43] <Lance> isn't it the case that the server never initiates a feature negotiation with a client? it's always started client side. so unless the client tries to negotiate two features at once, there shouldn't be anything else mixed in
[18:26:44] <ermine> oh, good point
[18:27:41] <dwd> Lance, Yeah, but this is using a entity-level feature, not a stream feature.
[18:27:50] <Lance> ooh
[18:28:23] * Minos joined the chat.
[18:28:28] * jmedev left the chat.
[18:30:00] <dwd> Informational Note: The client could exchange stanzas with the server itself or the client's account before binding a resource since the full JID is needed only for addressing outside the context of the stream negotiated between the client and the server, but this is not commonly done.
[18:30:23] <dwd> So I'm wrong - seems we allow this, in principle, but we say it's "not commonly done".
[18:31:47] <dwd> That said, a client is also required to immediately try to bind a resource once it's been informed that the server supports that feature.
[18:34:36] * MattJ joined the chat.
[18:36:06] <ermine> in fact i meant: c: <starttls xmlns.../> s: <iq xmlns="jabber:version"...> c: ?
[18:36:38] <ermine> well, aproximately :)
[18:36:45] <MattJ> Guus, you said you're reworking Openfire's s2s code?
[18:37:02] <MattJ> If so, can you (pretty please) make sure that it always sets a to/from on stream headers? :)
[18:37:11] <Zash> Pleeeeeeease
[18:37:23] <Guus> seriously, are you eavesdropping in another muc where we are just discussing this?
[18:37:31] * naw joined the chat.
[18:37:39] <ermine> MattJ: btw why prosody is afraid of seeing to attribute in iq bind?
[18:37:42] <MattJ> So many comments I could make :)
[18:37:58] <dwd> ermine, You can't do that, because you can't trust the response anyway.
[18:38:00] <Guus> if memory serves, there's a problem with backwards compatibility though. :/
[18:38:08] <MattJ> ermine, it's not afraid, if the to attribute is the user's bare JID
[18:38:24] <MattJ> Guus, well otherwise there is a problem with forwards compatibility :)
[18:38:49] <MattJ> Prosody's next release gets very upset with Openfire's current behaviour
[18:39:01] <MattJ> since we're more strict about to/from attributes
[18:39:03] <dwd> Guus, I think M-Link always sets the to/from attributes, and has been tested against quite a few different servers (including various variants of Openfire) with no issue.
[18:39:14] <ermine> MattJ: and always was disallowed? seems it was allowed a lot years ago
[18:39:19] <Zash> Prosody sets it allways too.
[18:39:29] <MattJ> ermine, ejabberd allows it. I don't think Prosody has ever allowed it
[18:40:21] <ermine> MattJ: yeah, ejabberd does not reject such stanza
[18:40:30] <MattJ> ermine, both the old and new RFCs specify bind stanzas without a 'to' attribute (which it later says is equivalent to to=<sender's bare JID>)
[18:41:52] <ermine> MattJ: i'm not complaining, i'm only interesting :)
[18:42:49] <MattJ> ejabberd used to do some other weird things (fixed now I believe), like handling vcard requests sent to full JIDs
[18:43:03] <MattJ> and a number of other things people reported as bugs against Prosody :)
[18:43:31] <dwd> MattJ, Really fixed? That relates to vCards in MUC - you need to do vCards differently instead of simply passing through.
[18:43:51] <MattJ> dwd, yes, I think that's how it happened
[18:43:53] <dwd> MattJ, FWIW, people reported them as bugs against M-Link, too.
[18:44:06] <MattJ> Its MUC relayed vcard requests to the full JID
[18:44:19] <MattJ> Presumably someone then fixed it the wrong way a long time ago :)
[18:44:29] <dwd> MattJ, Yes, as did Openfire's. Both respond to full jids for vCards, too.
[18:44:54] <MattJ> Our next release removes the compatibility code we have for that
[18:46:03] <Lance> oi, servers answering full jid requests. *shudders* gtalk used to do that for pings
[18:46:24] <Zash> Hrm
[18:46:45] <dwd> Lance, As I recall, iq:last needs to be handled that way, bizarrely.
[18:47:03] <Lance> no, full jid goes to client. bare jid is answered by server
[18:47:26] <MattJ> It's the rule.
[18:47:35] <Zash> The Rule!
[18:48:16] <Guus> MattJ / dwd: am I right to conclude that Openfire neglects to send the 'from' attribute when initiating S2S (and that there's no problem with the 'to' attribute)?
[18:48:40] <MattJ> I think that's the case, Zash was looking at it last
[18:48:46] <dwd> """ In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user. In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in XMPP IM), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a <forbidden/> error in response to the last activity request. """
[18:48:58] <dwd> XEP-0012, §4.
[18:49:13] <MattJ> !
[18:49:20] <dwd> Yeah. !.
[18:49:23] <Zash> "New stream 'from' attribute does not match original" it says.
[18:49:32] <MattJ> Shouldn't it be service-unavailable to prevent account discovery?
[18:49:45] <Lance> is the answer on behalf of the user meant to be tied in with presence? you're not on the roster so no iq:last for you
[18:50:18] <dwd> Lance, That's it. Better than that, it's from the bare jid instead of the full, in the example.
[18:50:33] <ermine> dwd: thx
[18:50:39] <MattJ> Guus, so yes, it's the 'from' attribute I think
[18:50:53] <Zash> MattJ, Guus: On the stream restart after EXTERNAL, the 'from' attribute must be equal to the authenticated identity or prosody gets upset.
[18:59:00] * Tobias joined the chat.
[19:02:36] * 0xAFFE left the chat.
[19:17:23] * jcea joined the chat.
[19:34:57] * ermine left the chat.
[19:37:38] * psa left the chat.
[19:37:38] * psa joined the chat.
[19:43:07] * Philonous joined the chat.
[19:56:35] <Guus> MattJ: the xmpp domain on igniterealtime.org should now be including a from attribute. Care to debug with me?
[19:57:34] * Bunneh joined the chat.
[19:58:01] <Zash> Bunneh, ping igniterealtime.org
[19:58:05] <Bunneh> Zash: Pong from igniterealtime.org in 3.946 seconds
[20:00:52] * psa left the chat.
[20:00:53] * psa joined the chat.
[20:02:20] * Lance left the chat.
[20:02:51] <Zash> Guus: Looks sane.
[20:03:48] <Guus> good
[20:04:48] <Guus> thanks
[20:09:52] * Lance joined the chat.
[20:19:35] * pidgin joined the chat.
[20:19:35] * pidgin left the chat.
[20:24:30] * Tobias left the chat.
[20:32:24] * stpeter joined the chat.
[20:35:00] * Zash left the chat.
[20:40:15] * psa left the chat.
[20:40:16] * psa joined the chat.
[20:51:19] * deryni left the chat.
[20:56:07] * Schnouki joined the chat.
[20:56:09] * Schnouki left the chat.
[20:58:28] * Zash joined the chat.
[21:13:09] <MattJ> Guus, great! :)
[21:35:23] * vorner joined the chat.
[21:37:26] * naw left the chat.
[21:47:12] * Tobias joined the chat.
[21:48:22] * stpeter left the chat.
[21:48:41] * psa left the chat.
[21:53:32] * vorner left the chat.
[21:55:19] * Guus left the chat.
[22:12:36] * StackOverflow left the chat.
[22:14:39] * Asterix left the chat.
[22:35:34] * Lance left the chat.
[22:39:18] * Zash left the chat.
[22:49:40] * Lance joined the chat.
[22:54:40] * deryni joined the chat.
[23:19:15] * MattJ left the chat.
[23:43:50] * Tobias left the chat.