Logs for jdev@conference.jabber.org

Show join/part/nick changes:

[00:06:13] * left the chat.
[00:06:29] * left the chat.
[00:16:08] * left the chat.
[01:30:07] * left the chat.
[01:30:21] * joined the chat.
[01:37:41] * left the chat.
[01:40:02] * joined the chat.
[02:09:13] * joined the chat.
[02:12:01] * joined the chat.
[02:14:44] * left the chat.
[02:53:43] * left the chat.
[02:53:51] * left the chat.
[03:04:05] * joined the chat.
[04:09:36] * left the chat.
[05:03:45] * joined the chat.
[05:26:42] * joined the chat.
[05:27:08] * left the chat.
[05:31:49] * joined the chat.
[05:52:36] * left the chat.
[06:23:31] * left the chat.
[06:51:02] * joined the chat.
[06:55:18] * left the chat.
[06:55:52] * joined the chat.
[06:57:04] * left the chat.
[06:57:59] * joined the chat.
[06:59:49] * left the chat.
[07:00:11] * joined the chat.
[07:00:35] * left the chat.
[07:04:38] * joined the chat.
[07:05:28] * joined the chat.
[07:09:55] * left the chat.
[07:10:43] * joined the chat.
[07:10:49] * left the chat.
[07:11:32] * joined the chat.
[07:13:22] * left the chat.
[07:20:45] * joined the chat.
[07:22:50] * joined the chat.
[07:38:40] * joined the chat.
[07:44:43] * left the chat.
[07:44:43] * joined the chat.
[08:17:51] * joined the chat.
[08:21:54] * joined the chat.
[08:22:27] <> Hello!
[08:52:40] * left the chat.
[08:59:58] * left the chat.
[09:13:33] * left the chat.
[09:22:33] * left the chat.
[09:23:38] * joined the chat.
[09:24:40] * joined the chat.
[09:37:51] * joined the chat.
[09:45:59] * left the chat.
[09:48:44] * left the chat.
[09:50:31] <> Kev, happen to know how m-link handles locked rooms where the user dies without letting the room know?
[09:51:01] <> Good question. If the user is local, not an issue.
[09:51:17] <> If the user is remote, it could be an issue.
[09:53:51] <> we were wondering in the prosody room the other day how to handle that day? maybe some periodical cleanup task going through all locked rooms and checking or so
[09:54:49] <> Right.
[10:20:16] * left the chat.
[10:22:47] * joined the chat.
[10:29:24] * left the chat.
[10:35:37] * joined the chat.
[11:18:07] * joined the chat.
[11:41:02] * joined the chat.
[11:54:57] * left the chat.
[12:14:03] * left the chat.
[12:18:55] * joined the chat.
[12:24:14] * joined the chat.
[12:24:38] * left the chat.
[12:30:20] * joined the chat.
[13:17:24] * joined the chat.
[13:37:38] * left the chat.
[13:57:04] * left the chat.
[14:09:23] * left the chat.
[14:09:42] * joined the chat.
[14:10:32] * left the chat.
[14:17:24] <> https://news.ycombinator.com/item?id=6520524
[14:19:23] <> urgh...that curly brackets community?
[14:19:24] <> ;)
[14:20:03] <> Tobias: I like this approach, though.
[14:20:28] <> xmpp-ftw?
[14:20:38] <> or matt's xep proposal?
[14:20:51] <> Tobias: you didn't actually read the comments, did you?
[14:21:22] <> i read it a couple hours ago, when there were about 4 comments
[14:22:21] <> Tobias: well, my first comment was the second on the page. So...
[14:22:39] <> haven't read that yet
[14:25:09] <> Tobias: :-D
[14:28:15] <> but sure...on API layer users don't have to see anything XML related, and probably shouldn't see, unless the actual payload is XML
[14:29:27] * left the chat.
[14:40:34] * joined the chat.
[14:53:26] * joined the chat.
[14:54:34] * joined the chat.
[14:56:15] * joined the chat.
[14:56:16] * left the chat.
[14:59:38] <> Tobias: right, and I think the approach of having a nice JS API to do pubsub with JSON payloads with XMPP under the hood is pretty nice.
[15:01:37] * joined the chat.
[15:05:17] * joined the chat.
[15:36:42] <> I'll add a pubsub example
[15:36:49] <> to replace the message one
[15:36:53] <> woot
[15:37:33] <> Otherwise I'll tread very carefully to not abuse the pre-approval :)
[15:40:49] * left the chat.
[15:42:29] * left the chat.
[15:42:30] * joined the chat.
[15:47:27] * joined the chat.
[15:50:19] * joined the chat.
[15:56:29] * left the chat.
[16:05:58] * left the chat.
[16:16:33] <> MattJ: :-)
[16:31:10] * left the chat.
[16:32:13] * left the chat.
[16:47:44] * left the chat.
[16:55:07] * joined the chat.
[17:01:53] * joined the chat.
[17:08:25] * joined the chat.
[17:11:15] * joined the chat.
[17:52:11] * left the chat.
[17:52:34] * joined the chat.
[18:02:10] <> i love when xeps are basically trivial to implement
[18:02:21] <> Lance: :-D
[18:02:27] <> https://github.com/legastero/stanza.io/commit/410e839f
[18:02:45] <> but but, it doesn't have a number yet
[18:03:36] <> also, I think the namespace will change before that it is published, right MattJ?
[18:03:37] <> :P
[18:03:47] <> but great to see indeed
[18:04:02] <> Right
[18:04:35] <> shall I s/tmp/0/ it?
[18:04:44] <> Hello! Do anyone know if item id should be used in PEP?
[18:04:52] <> MattJ please. get one ns change out of the way already
[18:04:53] <> I thought :0 was for Draft, or is that the Old Way now?
[18:05:15] <> Yagiza, hi
[18:05:31] <> MattJ
[18:05:36] <> Item IDs are used in PEP, they don't carry any significance as far as I know
[18:05:37] <> Yagiza: it depends on the payload format description
[18:05:48] <> Yagiza: most of them use 'current'
[18:05:53] <> MattJ: Well, how would you indicate incompatible version changes while still in experimental? :tmp:1?
[18:06:02] <> Yagiza: and then it is required
[18:06:20] <> Lance, I... can't remember :)
[18:06:38] <> I can't recall where this was even formalized, though I remember when namespace versioning was introduced
[18:07:35] <> ralphm, in examples in that document: http://xmpp.org/extensions/xep-0163.html item id never used!
[18:07:57] <> Then it gets chosen by the server
[18:07:57] <> MattJ: xep-53, it starts with :0 when it goes experimental
[18:08:03] <> Excellent
[18:10:02] <> Yagiza: good point. I think they are incorrect examples indeed. <- stpeter
[18:11:39] <> I tried using item id to retract items. Go different results with different implrmrntztion of PEP server.
[18:11:49] <> None of them was correct.
[18:11:53] <> Yagiza: I understand
[18:12:01] <> implementations
[18:13:02] <> Yagiza: Maybe I'm wrong about this, but I think that if you want any kind of item persistence (even only one item) you *must* have item identifiers, and clients should probably provide this to make sure you don't have multiple concurrent ones.
[18:13:19] <> For example, for something like User Tune, it doesn't really make sense to have more than one
[18:13:48] <> I thought we defined 'current' as the typical item identifier for this, but can't seem to find a reference
[18:14:06] * left the chat.
[18:14:13] * joined the chat.
[18:14:14] <> Ok
[18:14:35] <> Yagiza: http://xmpp.org/extensions/xep-0060.html#impl-singleton
[18:14:52] <> Yagiza: but yeah, I suppose all related XEPs don't make that very clear :-(
[18:15:15] <> MattJ, stpeter, Kev, opinions?
[18:16:03] <> > [19:07:56] MattJ: Then it gets chosen by the server
[18:16:12] <> is not right?
[18:16:23] <> that seems horribly bad for these examples
[18:16:38] <> MattJ: 'cause you'd get a new item for every tune you send
[18:17:01] <> MattJ: unless the server knows about the payload namespaces
[18:17:25] * left the chat.
[18:17:32] <> Right, but PEP was assumed to have only a single item allowed anyway
[18:17:59] <> MattJ: hence my reference to XEP-0060 12.20. But that'd require the *client* setting that
[18:18:27] <> of course, if you only keep one item, that problem is not as bad, but you can't assume this for all PEP use cases
[18:18:43] <> i.e. for some, you *want* more items
[18:19:04] <> Hmm, right
[18:19:36] <> Section 4.3.4 of XEP-0163 doesn't really make that clear, either
[18:20:10] <> Yeah
[18:20:29] <> So I, and Prosody, assumed that to mean a default of max_items = 1
[18:20:42] <> so IMHO, to do this right, all clients that publish to singleton nodes *MUST* set item id to 'current'
[18:20:46] <> no matter the id, you'll always replace the previous item
[18:21:02] <> but as we seem to be moving to full pubsub on JIDs... I think you're right
[18:21:10] <> it would save some confusion
[18:22:27] <> Gajim sends id="0"
[18:22:29] <> :-(
[18:24:24] <> MattJ: but yeah, having a default node configuration for pubsub#max_items set to 1 kind of fixes this
[18:24:43] <> it doesn't feel awesome though
[18:25:12] <> Maybe if you hadn't spent years thinking max_items=1 to be the official answer like I have
[18:25:58] <> I am a bit sad about this having escaped my attention
[18:26:42] <> /me is in a meeting IRL and is not paying close attention here
[18:26:49] <> stpeter: booh
[18:26:55] <> :P
[18:35:56] * left the chat.
[18:55:30] * joined the chat.
[19:01:00] <> yay, meetings are done, time for lunch
[19:02:00] <> hmph, did I miss some of the conversation here? it looks like our logs are broken since the migration in August so I can't check the entire history :(
[19:02:01] <> brb
[19:11:50] <> stpeter: yes, Kev apparently didn't think that was high priority
[19:11:57] <> :)
[19:12:04] <> (I asked before)
[19:12:39] <> ah, ok
[19:12:49] <> I can send you the transcript
[19:13:21] <> [20:07:35] Yagiza: ralphm, in examples in that document: http://xmpp.org/extensions/xep-0163.html item id never used! MattJ: Then it gets chosen by the server Lance: MattJ: xep-53, it starts with :0 when it goes experimental MattJ: Excellent ralphm: Yagiza: good point. I think they are incorrect examples indeed. <- stpeter Yagiza: I tried using item id to retract items. Go different results with different implrmrntztion of PEP server. Yagiza: None of them was correct. ralphm: Yagiza: I understand Yagiza: implementations [20:13:02] ralphm: Yagiza: Maybe I'm wrong about this, but I think that if you want any kind of item persistence (even only one item) you must have item identifiers, and clients should probably provide this to make sure you don't have multiple concurrent ones. ralphm: For example, for something like User Tune, it doesn't really make sense to have more than one ralphm: I thought we defined 'current' as the typical item identifier for this, but can't seem to find a reference stpeter (peter@jabber.org) has left stpeter (peter@jabber.org) has joined the group chat Yagiza: Ok ralphm: Yagiza: http://xmpp.org/extensions/xep-0060.html#impl-singleton ralphm: Yagiza: but yeah, I suppose all related XEPs don't make that very clear :-( ralphm: MattJ, stpeter, Kev, opinions? MattJ: > [19:07:56] MattJ: Then it gets chosen by the server MattJ: is not right? ralphm: that seems horribly bad for these examples ralphm: MattJ: 'cause you'd get a new item for every tune you send ralphm: MattJ: unless the server knows about the payload namespaces Yagiza (yagiza@isgeek.info) has left (I'm online!) MattJ: Right, but PEP was assumed to have only a single item allowed anyway ralphm: MattJ: hence my reference to XEP-0060 12.20. But that'd require the client setting that [20:18:27] ralphm: of course, if you only keep one item, that problem is not as bad, but you can't assume this for all PEP use cases ralphm: i.e. for some, you want more items MattJ: Hmm, right ralphm: Section 4.3.4 of XEP-0163 doesn't really make that clear, either MattJ: Yeah MattJ: So I, and Prosody, assumed that to mean a default of max_items = 1 ralphm: so IMHO, to do this right, all clients that publish to singleton nodes MUST set item id to 'current' MattJ: no matter the id, you'll always replace the previous item MattJ: but as we seem to be moving to full pubsub on JIDs... I think you're right MattJ: it would save some confusion ralphm: Gajim sends id="0" ralphm: :-( [20:24:24] ralphm: MattJ: but yeah, having a default node configuration for pubsub#max_items set to 1 kind of fixes this ralphm: it doesn't feel awesome though MattJ: Maybe if you hadn't spent years thinking max_items=1 to be the official answer like I have ralphm: I am a bit sad about this having escaped my attention * stpeter is in a meeting IRL and is not paying close attention here ralphm: stpeter: booh stpeter: :P [20:35:56] ermine (ermine@jabber.ru) has left [20:55:30] jabberjocke (jabberjocke@jabber.org) has joined the group chat
[19:13:36] <> no need, really :-)
[19:13:43] <> oh, too late
[19:13:56] <> :)
[19:14:21] <> stpeter: when you are done with lunch, I'd love to hear your view on this
[19:14:57] <> oh, I work while I eat
[19:15:15] <> BTW, I *can* see some Charles Ives kinds of use cases where you have 2 tunes at once ;-)
[19:15:32] <> (j/k)
[19:16:39] <> sure, if you have multiple devices
[19:20:03] <> hmmmmm
[19:21:29] <> MattJ: "So I, and Prosody, assumed that to mean a default of max_items = 1" what is "that"? Section 4.3.4 of XEP-0163?
[19:21:57] <> because I agree that a max_items of "1" is not defined anywhere in PEP
[19:22:10] <> or in XEP-0060
[19:22:50] <> It was too long ago :)
[19:22:51] <> I don't think we can safely say that max_items='1' is the default for PEP in general -- as Ralph says, it depends on the namespace
[19:22:54] <> hrmph
[19:23:22] <> which namespaces isn't it the case for?
[19:23:38] <> You're not allowed to say microblogging
[19:23:53] <> microblogging
[19:24:07] <> I consider that a special case :)
[19:24:13] <> heh
[19:24:17] <> yay snowflakes
[19:24:31] <> Apart from that, everything we have specified is purely notifications, no?
[19:24:34] <> this isn't about PEP vs. anything
[19:24:43] <> it is all pubsub eventually
[19:24:49] <> and it should be consistent either way
[19:25:18] <> Right, but PEP was a specific subset of pubsub - that doesn't seem to be where we're moving to today
[19:25:35] <> MattJ: sure it is a subset
[19:25:37] <> Everyone wants full a pubsub service on their JID
[19:25:53] <> I take that back
[19:26:00] <> MattJ: but you can't get rid of the basics. I consider item ids fundamental
[19:26:11] <> Everyone individually just wants features X, Y and Z from XEP-0060 to work in PEP
[19:27:57] * left the chat.
[19:30:17] <> yes, PEP is a subset, but it's not a subset that assumed max_items = 1
[19:31:40] <> I guess I misunderstood a XEP somewhere along then
[19:32:04] <> well
[19:32:20] <> I might argue that it's a good assumption, but IIRC it's not an assumption we made :-)
[19:32:42] <> mod_pep was implemented very early on, and we haven't done much to it since then... we're currently migrating it to use the same code as our "normal" pubsub implementation
[19:33:58] * left the chat.
[19:34:14] <> let's assume that all pep implementations are wrong :-D
[19:40:10] * joined the chat.
[19:50:12] <> ralphm: If ours is, I'd like to know :)
[19:50:34] <> Kev: your opinion is welcome. Have you read the above?
[19:50:39] <> Although I do have a few cases to re-test from when Remko wrote the Swiften tests.
[19:51:22] <> Several things seemed to be covered. Which did you want an opinion on? :)
[19:51:22] * left the chat.
[19:51:35] <> all of them
[19:51:42] <> but let's start with id='current'
[19:52:28] <> Whether items in PEP should have an id?
[19:53:19] <> I'm not sure the client actually needs to specify it, do they, unless they want to emulate max_items=1 on a node that is configured differently.
[19:53:21] <> Kev: well, whether clients should send an id, as per section 12.20 of XEP-0060
[19:53:42] <> (for singleton nodes)
[19:54:00] <> max_items=1 is a bit of a hack
[19:54:19] <> I think the opposite, I think id=current is a bit of a hack, and max_items is the sensible solution.
[19:54:22] <> if you want to express 'current song' or 'current location'
[19:54:25] <> But you say potato ... :)
[19:56:20] <> I suppose you could argue that different values should have different ids
[19:57:03] <> I think that you can look at e.g. 'client settings' and say that keeping some history is sensible, so you can undo or whatever.
[19:57:04] <> but in that case, still, XEP-0163 and the respective format XEPs should at least show server-generated item ids in the notification examples
[19:57:55] <> And so whether you keep 1 with no backups, 2 items (1 backup), or 20 items is a matter of node configuration, so setting id='current' shouldn't change depending on whether you have backups or not.
[19:58:07] <> But this is off-the-cuff comment, rather than anything I've considered at length.
[19:58:07] <> true
[19:58:17] * left the chat.
[19:58:24] <> But yes, 163 should probably at least show the server-generated ids.
[19:58:24] <> Kev: I'm sure you're quick of reasoning :-D
[19:58:44] * joined the chat.
[19:59:34] <> Fast/Good/Cheap, pick two :)
[20:03:03] * joined the chat.
[20:04:05] * joined the chat.
[20:04:13] * joined the chat.
[20:04:20] * left the chat.
[20:04:27] * joined the chat.
[20:06:02] <> I agree with Kev, id='current' is a hack
[20:09:04] <> why do we RECOMMEND it then?
[20:09:20] <> Nobody's perfect.
[20:09:22] <> because it was the best we could come up with at the first XMPP summit
[20:09:41] <> hm
[20:10:00] <> it's also a hack to do presence subscriptions using the <presence/> stanza
[20:10:04] <> lots of hacks :-)
[20:10:21] <> Hmm. You think so?
[20:10:23] <> that's certainly more horrible
[20:10:27] <> I never saw that as particularly terrible.
[20:10:27] <> IMO
[20:10:45] <> if I were to do that part again, all roster actions would be iqs
[20:11:09] <> Oh, I think the same is true for me.
[20:11:14] <> I just don't think it's particularly bad as it is.
[20:11:44] <> it is kinda weird as you don't get proper one-on-one request response for presence
[20:11:56] <> none of them use id attributes, for example
[20:12:56] <> A fair point.
[20:35:28] * joined the chat.
[20:49:09] * left the chat.
[20:50:45] * joined the chat.
[21:04:21] <> I got a jabberd2 server saying <address xmlns='http://affinix.com/jabber/address'>Some IPv6 address</address> in the the stream features, what is that?
[21:04:54] <> I haven’t found anything on the web about it.
[21:05:09] <> I guess no client will use it.
[21:19:39] * left the chat.
[21:28:50] * joined the chat.
[21:28:59] <> Link Mauve: looks silly
[21:29:50] <> It can also be a ::ffff:a.b.c.d mapped IPv4.
[21:30:17] * left the chat.
[21:30:25] <> I'm sure justin can fill you in on that
[21:30:35] <> I invited him over
[21:32:24] * joined the chat.
[21:32:44] <> hello
[21:33:10] <> justin: hi, Link Mauve wants to know about your fancy stream features
[21:33:33] <> fancy? :)
[21:33:47] <> underdocumented?
[21:34:37] <> That kind of stream feature: <address xmlns='http://affinix.com/jabber/address'>Some IPv6 address</address>
[21:34:47] <> ah yes
[21:35:18] <> the intent is that it's a text IP address, so either ipv4 or ipv6
[21:35:47] <> Is there a single client using it?
[21:36:02] <> doubtful
[21:37:05] <> it was something a lot of people talked about wanting, and i think there are other approaches too, like some servers putting the address in an attribute of <stream>
[21:37:14] <> i'm not sure who does what
[21:37:57] <> What would be the purpose? You are already connected to the server with that same address, you are supposed to know it.
[21:38:26] <> Link Mauve: feature requests are often not rational
[21:38:34] <> the idea is to obtain what is likely your internet-facing IP address
[21:38:44] <> Link Mauve: have you ever worked on a software project with 'stakeholders'?
[21:38:47] <> which if you're behind NAT, you might not know
[21:38:54] <> Oh, so it would be the one I do the request with?
[21:39:01] <> A kind of STUN then.
[21:39:05] <> Makes sense.
[21:39:31] <> right. and i was going to say, these days you need STUN to get anything done anyway, so that might be the ideal way to get this info
[21:39:34] <> Except it usually helps nothing
[21:39:44] <> right
[21:40:41] <> outside of STUN hole-punch magic it could be used in combination with port forwarding. but we're at the point where really nobody should ever have to port forward...
[21:41:07] <> Let’s all abandon IPv4!
[21:42:38] <> http://xmpp.org/extensions/xep-0279.html ?
[21:43:15] <> we could make that a stream feature, of course, but that feels a bit strange to me
[21:44:16] <> is that used at all?
[21:44:30] <> ralphm: maybe -- we'd have to ask Diana
[21:45:23] <> /me needs to ping Thiago, too
[21:49:33] <> if only we had a thing where you could ping multiple entities at the same time...
[22:16:13] * left the chat.
[22:18:47] * left the chat.
[22:19:23] * left the chat.
[22:20:30] * left the chat.
[22:23:38] * left the chat.
[22:26:18] * joined the chat.
[22:28:54] * left the chat.
[22:30:13] * joined the chat.
[22:37:27] * left the chat.
[22:42:36] * joined the chat.
[23:05:01] * left the chat.
[23:10:52] * left the chat.
[23:16:50] * left the chat.
[23:16:50] * joined the chat.
[23:18:40] * joined the chat.
[23:47:48] * left the chat.
[23:47:48] * joined the chat.