XSF Discussion - 2017-10-05

00:19:47 Guus has left
00:25:27 Tobias has left
00:33:02 Wiktor has left
00:33:09 Wiktor has joined
00:36:16 Tobias has joined
00:37:36 Tobias has left
00:40:49 jere has left
00:40:56 jere has joined
00:41:48 waqas has left
00:44:23 Tobias has joined
00:45:17 Valerian has left
00:45:26 Valerian has joined
00:50:10 Tobias has left
00:50:33 lovetox has left
01:02:23 Valerian has left
01:04:23 lskdjf has joined
01:05:15 la|r|ma has joined
01:18:20 tux has left
01:20:00 lskdjf has left
01:20:04 lskdjf has joined
01:20:57 tux has left
01:24:48 tux has left
01:24:50 tux has joined
01:26:46 lskdjf has joined
01:26:51 lskdjf has joined
01:27:26 Tobias has joined
01:32:46 efrit has left
01:41:41 tim@boese-ban.de has left
01:41:46 tim@boese-ban.de has joined
01:48:40 intosi has left
02:00:56 jjrh has left
02:05:53 Lance has joined
02:06:09 Lance has left
02:06:17 Lance has joined
02:06:48 jjrh has left
02:07:43 waqas has joined
02:07:44 Tobias has joined
02:09:15 Lance has left
02:09:57 lskdjf has joined
02:16:44 lskdjf has joined
02:24:32 la|r|ma has joined
02:42:14 la|r|ma has joined
02:45:36 lskdjf has joined
02:56:11 jjrh has left
02:58:16 jjrh has left
03:03:53 jjrh has left
03:04:49 jjrh has left
03:07:19 tim@boese-ban.de has left
03:11:05 Tobias has left
03:14:13 tux has left
03:14:15 tux has joined
03:17:08 tim@boese-ban.de has joined
03:21:33 la|r|ma has joined
03:26:27 jere has left
03:26:33 jere has joined
03:46:07 nyco has left
03:52:32 zinid has left
03:59:23 zinid has joined
04:00:51 jjrh has left
04:01:16 jjrh has left
04:04:26 jere has left
04:04:38 jere has joined
04:05:07 SamWhited has left
04:06:40 jjrh has left
04:22:01 daniel has joined
04:24:17 sezuan has joined
04:37:32 uc has joined
04:37:40 daniel has left
04:41:31 zinid has left
04:42:55 jubalh has joined
04:43:02 zinid has joined
04:44:59 waqas has left
04:46:07 jubalh has left
04:46:10 jubalh has joined
04:57:16 Guus has left
05:03:20 daniel has joined
05:12:09 Tobias has left
05:19:03 jubalh has left
05:24:41 stefandxm has left
05:26:10 stefandxm has joined
05:29:19 uc has joined
05:36:38 Guus has left
05:41:25 uc has joined
05:43:18 jonasw moparisthebest, a change from SHOULD to MAY is a technical change. However, given that there has no advancement been made to the XEP yet, that’ll be fine
05:43:21 jonasw I guess this is what the CFE is for
05:43:26 jubalh has joined
05:43:42 stefandxm has left
05:43:55 Guus has left
05:48:42 uc has joined
05:49:58 daniel has left
05:51:56 Kev Well, it's for Council to decide whether it's fine or not, no?
05:52:23 jonasw Kev, yes
05:52:23 stefandxm has joined
05:52:29 jonasw you’re right about that
05:52:37 jonasw what I meant is: it is not absolutely not fine
05:53:16 jonasw and also council members brought that change I assume moparisthebest will do up in the discussion, so ... ;-)
05:54:41 daniel has joined
05:57:19 Guus has left
05:58:32 goffi has joined
05:59:51 intosi has joined
06:04:14 tim@boese-ban.de has left
06:04:18 tim@boese-ban.de has joined
06:10:49 Tobias has left
06:14:21 daniel has left
06:14:59 daniel has joined
06:17:30 Guus Kev (others): please elevate me from member to owner on our github repo, add me to the team on dockerhub, and provide me with the twitter credentials. It'd be good to have someone else be available to help people out with requests in order to speed up things (and as I'm currently the requestee most of the time, who's also in iteam, I'd be a logical candidate).
06:23:41 Guus has left
06:26:27 Kev What's your name on the docker hub?
06:28:10 edhelas has left
06:28:11 Kev You've got ownership of the github org now, I'll sort out docker at some point later when I know your account, and Twitter I need to sort out password changing and distribution of the password.
06:28:29 Kev Please don't change things without discussion.
06:28:33 edhelas has joined
06:30:36 Guus Thanks, I won't
06:30:40 Guus I'm guusdk on dockerhub
06:43:15 uc has joined
06:43:50 daniel has left
06:45:17 daniel has joined
06:46:13 tim@boese-ban.de has joined
06:46:42 tim@boese-ban.de has joined
06:49:09 Guus has left
06:56:23 Ge0rG has left
07:00:17 Kev has left
07:00:33 tim@boese-ban.de has joined
07:00:48 tim@boese-ban.de has joined
07:04:09 jcbrand has joined
07:09:28 nyco has left
07:25:30 sezuan has left
07:37:03 sonny has joined
07:39:57 Ge0rG has left
07:44:05 jcbrand has left
07:49:26 zinid has left
07:49:35 zinid has left
07:49:59 zinid has joined
07:50:23 uc has joined
07:52:20 winfried has joined
07:54:32 winfried has left
07:54:59 Ge0rG has left
07:58:19 jubalh has joined
08:09:57 Ge0rG has left
08:13:00 tim@boese-ban.de has joined
08:13:17 tim@boese-ban.de has joined
08:17:00 winfried has left
08:20:10 Martin has joined
08:24:57 Ge0rG has left
08:28:32 uc has joined
08:35:26 tim@boese-ban.de has joined
08:39:57 Ge0rG has left
08:43:55 winfried has left
08:48:09 Zash has left
08:49:11 winfried has joined
08:56:09 jubalh has joined
08:57:14 Ge0rG has left
08:57:26 zinid has left
09:06:05 zinid has left
09:12:14 Ge0rG has left
09:15:45 Martin has left
09:25:38 Guus has left
09:29:46 Ge0rG has left
09:37:14 Martin has joined
09:42:33 Ge0rG has left
09:43:08 lumi has joined
09:43:31 andrey.g has left
09:46:11 sonny has left
09:47:50 andrey.g has joined
09:54:16 lovetox has joined
09:55:57 andrey.g has joined
09:57:12 stefandxm has left
09:57:35 Ge0rG has left
10:00:23 lovetox has left
10:03:05 lovetox has joined
10:03:53 andrey.g has joined
10:11:59 mimi89999 has joined
10:12:01 andrey.g has joined
10:16:05 Guus when establishing (direct) ssl, is more than one socket connection involved (is a connection re-established?)
10:16:36 zinid has left
10:17:03 matlag has left
10:17:22 matlag has joined
10:19:55 andrey.g has joined
10:25:30 zinid has left
10:28:12 Alex has joined
10:28:39 andrey.g has joined
10:30:37 jonasw Guus, no
10:30:45 Guus has left
10:30:46 jonasw you start TLS over the existing TCP connection
10:30:53 stefandxm has joined
10:31:10 Zash Just like STARTTLS, except without the negotiation
10:31:26 Guus sounds like it's time to shout at apache mina again then
10:33:46 Link Mauve Zash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/
10:34:52 Zash That hurt my head
10:35:12 lovetox has left
10:35:30 Zash Depends on how your libraries work I guess
10:35:42 stefandxm has left
10:40:59 lumi has left
10:41:56 mimi89999 has joined
10:45:06 Ge0rG has left
10:48:59 Kev has left
10:49:32 Guus has left
10:50:10 Zash has left
10:50:10 Zash has left
10:51:41 Zash has joined
10:52:29 winfried has joined
10:52:30 winfried has joined
11:03:39 Guus has left
11:10:03 Ge0rG It's a great way to shave off some round-trips, though
11:11:49 Guus has left
11:13:13 jubalh has joined
11:18:52 jubalh has left
11:19:32 Alex has left
11:20:05 Ge0rG Kev: "undesirable"... I love your choice of words!
11:21:23 Alex has joined
11:21:24 jonasw undesirable in that context might be the XMPP-related understatement of the decade :-)
11:21:32 Ge0rG Kev: killing GC1 was brought up to the council, but without a well worded motivation. I also agree we need to kill it, but it is to some degree a better resync mechanism than nothing at all.
11:21:52 Kev It is definitely better than nothing at all.
11:22:19 Kev I've long held that opinion. But if we're providing something better now, maybe it can retire.
11:22:31 Ge0rG Kev: except when you end up seeing ghosts in the MUC.
11:23:04 zinid has left
11:23:12 Kev You see ghosts in the MUC with or without gc1 joins, without another mechanism.
11:23:25 Kev Without gc1, everyone you see (as a client) is a ghost :)
11:24:11 lumi has joined
11:24:53 Ge0rG Kev: yes, but then you realize that as soon as you send a message.
11:25:13 Kev That is true.
11:25:29 Ge0rG Kev: my point is that it's not always better than nothing.
11:25:43 Zash If we get rid of gc1, isn't a normal presence the same as <presence><I-expect-to-still-be-in-the-room/></p>
11:26:11 Kev If you're referring to (3), then no.
11:26:13 jonasw Zash, yes, but we can’t simply get rid of GC1, can we?
11:26:20 Zash Can we?
11:26:20 Kev jonasw: Can't we? :)
11:26:27 jonasw Kev, council was against it.
11:26:35 jonasw I mean, we can re-try, but ...
11:26:49 jonasw speaking of council, still no (re-)applications?
11:26:55 Kev Council may have been against it when there wasn't a better option, they may not be after this.
11:27:13 Kev Only Joe Demo, by the look of it.
11:27:34 Kev I hear good things about that guy.
11:27:46 jonasw like Boaty McBoatface?
11:28:02 Ge0rG Again, I want to propose Boardy McBoardface for Council.
11:28:16 jonasw not Council McCouncilface?
11:28:32 Ge0rG jonasw: no. C McC should apply for Board instead.
11:30:54 la|r|ma has joined
11:31:10 jonasw for maximum confusion, I see
11:31:32 Ge0rG I wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.
11:31:35 Ge0rG has left
11:31:56 Ge0rG Killing GC1.0 would be my major campain promise.
11:32:27 jonasw hm, one can’t really make promises, can one?
11:32:31 jonasw when running for council
11:32:38 zinid has left
11:32:55 jonasw (well, one can... but in the end it all depends on who else gets elected. then again, that’s the same for all elections)
11:37:10 Guus has left
11:40:33 Kev I kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.
11:40:55 andrey.g has left
11:40:57 jonasw you can’t really do implementation without some specification
11:41:02 Kev Of course you can.
11:41:13 Zash Just type code into your thing!
11:41:15 Kev You try something and see if it works.
11:41:16 jonasw well, you shouldn’t
11:41:18 jonasw hm
11:41:21 Kev Also, completely untrue.
11:41:31 Zash So you are a specification before implementation person?
11:41:39 Kev Protocol documents based on people actually trying things is a jolly good thing.
11:41:47 Zash Some are the other way around. Some think both at the same time!
11:41:48 jonasw yeah, I see where you’re coming from
11:42:29 Kev Everything has its place. Except the things that don't.
11:42:33 jonasw I’m not necessarily, but Session 2.0 is a thing where many parties need to play together, so there needs some kind of coordination, that is, specification, on what the parties implement each
11:42:53 Kev jonasw: Nothing says that has to happen in advance.
11:42:59 jubalh has joined
11:43:00 Ge0rG Kev: I could implement Session 2.0, but then it would only work for IM.
11:43:17 Kev e.g. if I had spare person-hours, I'd have something that worked implemented in M-Link and the Swifts, and we could use that experience to feed into the specs.
11:43:21 uc has joined
11:44:14 Kev Ge0rG: Sure. But 'try stuff and see if it works' doesn't mean 'specify what was implemented and treat it as set in stone because you coded some prototype'.
11:46:11 andrey.g has joined
11:46:25 Guus has left
11:46:42 Ge0rG has left
11:47:52 Ge0rG Kev: I also need to read up what I have "proclaimed" in the last two years under the "MUC-subscription" label. I think it's all the same basic idea, and maybe I forgot something important in the last iteration
11:48:13 jonasw itym MAM-subcsription
11:48:27 Ge0rG jonasw: right. Sorry. I won't LMC that now.
11:49:59 Kev Ge0rG: I *think* the important thing there is simply that everything that's chat-related you want both in your archive and on all your devices.
11:50:13 Kev So all we need to do is achieve that :D
11:51:04 Zash So how do we determine if a message is "chat-related"?
11:51:20 Kev I did the hard work of coming up with the high-level direction. Someone else can work on the details.
11:51:23 Zash type=chat would have been nice
11:53:54 Ge0rG Kev: you are a genius! Why didn't anyone else think of that before? :D
11:54:14 Ge0rG Zash: 0184 and CSNs happen to be type=random.
11:54:15 nyco has left
11:54:45 jonasw also, what about type=normal? :)
11:54:47 Zash Aren't those chat related?
11:54:50 Guus has left
11:54:53 Ge0rG Zash: maybe they are.
11:54:58 jonasw that certainly has messaging use-cases too, and wouldn’t you want to sync them, too?
11:54:58 mimi89999 has joined
11:55:04 Ge0rG jonasw: chat is the new normal.
11:55:09 jonasw that’s your opinio.n
11:55:13 jonasw ;-)
11:55:16 Ge0rG jonasw: that's what implementations do
11:55:24 jonasw because no implemntation has a UI for type=normal
11:55:37 jonasw except pidgins "let’s show this in a separate window focus stealingly" counts as UI
11:56:19 Ge0rG jonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"
11:56:35 jonasw meh.
11:56:45 Ge0rG Like for example ACKs.
11:56:46 Zash -xep 304
11:56:46 Bunneh Zash: XEP-0304: Whitespace Keepalive Negotiation (Standards Track, Deferred, 2011-08-18) See: https://xmpp.org/extensions/xep-0304.html
11:57:32 Ge0rG jonasw: also guess which message type is mandated by [xep 0184]
11:57:40 jonasw "whatever works"?
11:57:53 Zash Ge0rG: {}
11:58:28 Ge0rG Zash: -ETOOMANYDIFFERENTBOTS
11:58:39 Zash Bots bots bots
11:58:52 Ge0rG can't we just have all bot react to all patterns, instead of putting the cognitive load onto people?
11:59:05 Zash Wasn't both 184 and csn using the standard reply pattern? Ie same type
11:59:27 Ge0rG -xep standard reply pattern
11:59:27 Bunneh Ge0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28) See: https://xmpp.org/extensions/xep-0068.html
11:59:40 andrey.g has joined
12:00:24 Zash Copy attributes, swap to/from. If it's an error, set type=error.
12:00:45 Ge0rG Zash: There is no such primitive in the XMPP lib I'm using.
12:01:41 jonasw Ge0rG, switch XMPP libs then!
12:02:01 Ge0rG has left
12:02:21 jonasw Zash, also, you shouldn’t be copying the @id for anything except IQ, I think
12:02:22 Ge0rG Zash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?
12:03:01 Kev I think acks you probably want stored in your archive, while CSNs you certainly don't.
12:03:13 Zash Kev: Are you sure?
12:03:25 Ge0rG Right. ACKs need to be archived.
12:03:27 Kev Actually, I'm fairly sure you want something more sophisticated than just putting acks in your archive, but I'm not sure how revolutionary I should be today.
12:03:40 jonasw Kev, as much as possible, of course.
12:03:50 Ge0rG Kev: it's all about synchronizing a chat database.
12:04:07 Ge0rG Kev: yes please. Make the most revolutionary proposal you can imagine.
12:04:15 winfried has joined
12:04:45 Kev Have your server handle your acks for you. Also have the server archive read receipt status for your messages.
12:05:07 Kev Have the ability to collate messages that operate on each other in the archive, so they can be returned as state on the MAM results.
12:05:10 Ge0rG Kev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID
12:05:26 Kev Delivered, Read, LMC. Store them, but on the message they affect, not on their own.
12:05:42 Ge0rG Kev: that message collation would work much better if we had properly-generated UUIDs
12:06:00 Ge0rG Does "unique" also mean that there should be only one UUID per message?
12:06:00 Zash Kev: I object to anything that makes it impossible to do MAM in an append-only log store thing.
12:06:32 Ge0rG Kev: BTW that almost sounds like a multi-table relational database
12:06:43 Zash I object to anything that requires a relational database.
12:07:23 Ge0rG Zash: better apply for Council now, then
12:09:13 Kev I think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.
12:11:10 Ge0rG Kev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?
12:11:29 Kev Synchronise in which sense?
12:11:34 Ge0rG This is again the fully-synchronized fat client vs. load-on-demand thin client debate I think
12:11:53 Kev Possibly.
12:12:10 Ge0rG For load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.
12:12:25 Ge0rG For fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.
12:12:51 Kev That is possibly true.
12:13:05 Ge0rG Now this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.
12:13:06 Martin has left
12:14:01 jonasw isn’t that already a thing in {XEP 0280}?
12:14:04 jonasw damnit
12:14:16 Zash -xep carbons
12:14:16 Ge0rG jonasw: no
12:14:16 Bunneh Zash: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html
12:14:24 jonasw no, I misremember
12:14:43 Ge0rG jonasw: I tried to bring that up a year ago or two, and there were very loud voices arguing against that, because of sysload
12:14:50 Yagiza has joined
12:14:52 Zash I think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back
12:14:52 jonasw what
12:15:00 Zash syswhat
12:15:11 Kev I'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.
12:15:20 Ge0rG If I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198
12:15:28 lumi has left
12:16:02 Ge0rG Kev: maybe except for https://xmpp.org/extensions/xep-0047.html#message
12:16:24 jonasw what’s session in this context?
12:16:46 Ge0rG jonasw: that thing you bind.
12:17:15 jonasw ah
12:17:46 Ge0rG jonasw: what I mean is: have a separate session type (XMPP2, MAM-sub or whatever you name it), which replaces carbons and 0198 with a logic that feeds back MAM IDs for sent messages and either Carbons or direct messages of all incoming data
12:18:06 Ge0rG has left
12:18:13 Ge0rG I'm not opposed to the Carbons wire format, just the current processing logic is insane.
12:18:55 jonasw sounds reasonable
12:19:01 jonasw still possible to do that even without redoing xmpp
12:19:42 Kev Everything's possible without redoing xmpp :)
12:19:54 Ge0rG jonasw: still doesn't solve the persistency/urgency problem.
12:21:49 jonasw Ge0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?
12:22:36 Ge0rG jonasw: are there any final XEPs at all? I thought Draft is the new Final.
12:23:47 jonasw XEP-0030 :)
12:23:52 jonasw (for example)
12:24:20 moparisthebest I'm pushing to make 368 final
12:24:33 moparisthebest but also considering I nor any current editors have ever seen a move to final
12:24:37 moparisthebest no
12:25:04 valo has joined
12:25:04 jonasw moparisthebest, no worries :)
12:25:17 jonasw just prepare your PR and see what council says.
12:25:36 lumi has joined
12:25:40 moparisthebest yea I'm just agreeing with Ge0rG here, final isn't a thing, draft is final
12:26:12 daniel has left
12:26:21 daniel has joined
12:28:36 jere has joined
12:30:08 daniel has left
12:30:25 daniel has joined
12:36:08 Ge0rG has left
12:36:14 Kev I think that might have something to do with our habit of getting something 'good enough' but not quite right, and so not being willing to advance it further.
12:37:50 Guus has left
12:44:46 daniel has left
12:44:56 daniel has joined
12:46:58 sonny has joined
12:47:11 Ge0rG has left
12:49:38 lskdjf has joined
12:51:29 la|r|ma has joined
12:56:04 uc has joined
12:56:21 uc has joined
12:58:57 winfried has joined
13:00:10 lumi has left
13:01:21 waqas has joined
13:01:51 Ge0rG has left
13:03:02 Martin has joined
13:16:47 Ge0rG has left
13:21:24 Ge0rG has joined
13:22:16 Wiktor has joined
13:22:16 Wiktor has left
13:22:41 Wiktor has joined
13:23:25 winfried has joined
13:26:17 Flow has joined
13:26:33 tux has joined
13:31:23 Wiktor has joined
13:31:26 Wiktor has left
13:31:36 Wiktor has joined
13:33:16 Flow has left
13:35:42 Flow has joined
13:37:14 stefandxm has left
13:42:32 Flow isn't the question what the benefit of final XEPs is, over draft XEPs?
13:42:43 Flow as far as I can tell, final only has disadvantages
13:46:38 jonasw Flow, what advantages does Draft have over Experimental? :)
13:47:29 Flow jonasw: another review round at least by the council and probably by the xmpp community
13:47:44 jonasw okay
13:47:50 jonasw then final probably doesn’t bring you anything :)
13:48:02 Flow plus at least so und so many implementations IIRC
13:49:38 jonasw that’s only with Final IIRC
13:50:06 Flow ahh right
13:51:28 Ge0rG has left
13:53:27 Flow ok, so after reading xep1 once more and to sum up: final has the disadvantage that no namespace bumps can be made, which is probably not an issue (see ecaps2). And the advantage that feedback was given and there are multiple interoperable implementations required
13:53:39 Flow (I was thinking that this was for draft)
13:55:02 jubalh has joined
13:55:57 la|r|ma has joined
13:56:40 lskdjf has joined
14:05:27 Ge0rG has left
14:14:45 daniel has left
14:14:55 daniel has joined
14:16:30 intosi has left
14:17:20 Martin has left
14:18:22 stefandxm has joined
14:20:06 jubalh has left
14:21:38 jubalh has joined
14:22:50 Martin has joined
14:23:11 jubalh has left
14:23:13 jubalh has joined
14:33:18 daniel has left
14:35:15 Ge0rG There is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?
14:35:49 intosi has joined
14:36:34 stefandxm has left
14:37:11 SamWhited Ge0rG: they are not treated differently, changing the namespace is forbidden in final.
14:37:46 Ge0rG SamWhited: yes, so we end up with a new XEP with a new namespace instead.
14:38:16 SamWhited Ge0rG: Yes, that's the point, after something has reached final if you want to replace it you need to create a new XEP.
14:38:41 Ge0rG has left
14:38:58 Ge0rG SamWhited: yes, I'm merely questioning the wisdom of that
14:40:13 SamWhited I don't even know where to begin with that… you want XEPs to never stabalize? We have enough problems with people not wanting to implement experimental XEPs because they're a moving target without saying that all XEPs have the potential to change and break compatibility and fragment the ecosystem at any time.
14:40:56 SamWhited I'm all for going to final slowly, it's nice to have the flexibility to change things, but at some point when things are widely implemented we need to stop breaking compatibility and call it "good enough".
14:42:12 Flow has left
14:43:17 stefandxm has joined
14:47:55 Ge0rG has left
14:59:21 Flow has joined
14:59:31 daniel has joined
15:05:27 Guus has left
15:06:59 Flow has left
15:09:57 lumi has joined
15:16:25 la|r|ma has joined
15:16:35 Guus has left
15:19:16 Ge0rG SamWhited: I'm just some random smartass, questioning everything. But I also wondered if other parts of our process might be improvable.
15:19:28 Ge0rG has left
15:19:30 Ge0rG has left
15:22:13 Guus has left
15:25:16 Ge0rG has left
15:29:45 Guus has left
15:31:42 stefandxm has left
15:35:07 savostin has joined
15:51:01 nyco has left
15:55:35 Guus has left
15:57:12 matlag has left
15:57:49 Martin has left
15:57:49 Martin has joined
15:58:20 matlag has left
15:59:48 Guus has left
16:00:46 Martin has left
16:03:02 matlag has left
16:03:34 SamWhited I definitely think there's room for improvement, but never stabalizing anything probably isn't it.
16:03:52 matlag has left
16:05:26 Martin has joined
16:06:13 daniel has left
16:07:48 mhterres has joined
16:07:48 mhterres has left
16:09:34 nyco has left
16:14:39 Ge0rG has left
16:16:08 uc has joined
16:16:37 matlag has left
16:20:19 waqas has left
16:26:20 Ge0rG has left
16:26:24 Ge0rG has left
16:26:42 jubalh has joined
16:26:52 jere has joined
16:27:01 jubalh has joined
16:30:51 jere has joined
16:32:24 jubalh has left
16:33:37 waqas has joined
16:36:31 lumi has left
16:37:34 mimi89999 has joined
16:43:34 Ge0rG has left
16:43:35 Ge0rG has left
16:46:06 sonny has left
16:46:08 sonny has joined
16:49:10 jjrh has left
16:52:09 Ge0rG has left
16:54:59 Yagiza has left
16:57:53 intosi has left
17:01:37 mimi89999 has joined
17:02:41 emxp has joined
17:02:44 emxp has joined
17:03:11 jjrh has left
17:04:37 mimi89999 has joined
17:04:50 jjrh has left
17:05:20 jjrh has left
17:05:35 Martin has left
17:06:13 Martin has joined
17:12:57 nyco has left
17:14:29 sonny has left
17:14:31 sonny has joined
17:15:16 stefandxm has joined
17:15:17 Valerian has joined
17:20:12 winfried has joined
17:21:09 ralphm has left
17:29:51 Valerian has left
17:30:06 Flow has joined
17:30:08 Flow has left
17:30:09 Flow has joined
17:31:24 stefandxm has left
17:41:12 Valerian has joined
17:42:55 Valerian has left
17:51:21 mimi89999 has joined
17:55:39 Flow has left
17:55:40 Flow has joined
17:56:53 jonasw yeah
17:57:00 jonasw I’m already not happy with XEPs changing at all
17:57:26 Ge0rG Except when they are made better?
17:58:10 jonasw even draft xeps sometimes undergo massive changes, see Bookmarks.
18:00:58 Ge0rG I'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.
18:01:22 moparisthebest same with omemo?
18:02:11 jubalh has joined
18:02:29 jonasw no, OMEMO has a XEP reflecting the current state now
18:02:43 Ge0rG I'm not implementing OMEMO because the deployed protocol is not specified, the specified protocol is not deployed, because it adds major UX bumps and because I don't believe in E2EE.
18:02:52 Ge0rG jonasw: oh, it does?
18:03:10 jonasw it uses the siacs namespace at least
18:03:28 zinid the problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying
18:03:56 jonasw another issue I have with that is that old versions are barely discoverable
18:04:14 jonasw you could see a XEP for the first time a day after the last namespace bump, implement it, and see that nobody implements that version in the wild yet
18:04:21 Ge0rG zinid: we can't bump the namespace on MUC, fortunately.
18:04:50 zinid Ge0rG: and we resorted to replace this monster with another monster?
18:05:12 Ge0rG zinid: MUC is not a monster. It's ugly, but it's not too large.
18:06:09 zinid I have 4000 LOC of mod_muc* modules, isn't this a monster?
18:06:33 Martin has left
18:06:49 zinid if it's not a monster, then what it is? I can recall pubsub only
18:07:01 Zash Huh
18:07:26 Ge0rG zinid: you know, bad specification is not the only cause of bloated software.
18:07:29 Ge0rG Sometimes the problem is in front of the terminal, actually.
18:08:07 jubalh has left
18:08:11 jubalh has joined
18:08:15 moparisthebest ‎[02:06:51 PM] ‎Ge0rG‎: *snip* I don't believe in E2EE.
18:08:17 moparisthebest what
18:08:49 moparisthebest what possible reason could you not believe in E2EE, and in what way
18:09:37 Zash It's not the golden saviour of humanity as some would have you believe
18:09:52 Ge0rG moparisthebest: E2EE is often advertised as the solution to dragnet surveillance, but it doesn't fix the biggest problem: three-letter agencies are interested in meta-data more than in actual content.
18:09:59 Zash Also it invalidates a bunch of the assumptions XMPP is built on
18:10:14 Ge0rG moparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.
18:10:27 mimi89999 has joined
18:10:39 Ge0rG moparisthebest: if you really want to prevent meta-data collection, you must run your own server for family&friends. And then you don't need E2EE any more.
18:11:22 jonasw (I find that argument rather convincing, by the way. And I belong to the group of people who’re still using OTR, because reasons)
18:11:23 moparisthebest so I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though
18:11:52 jonasw it does
18:11:52 moparisthebest I run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?
18:12:03 jonasw take a look at the number of people complaining about issues with OMEMO and blaming it on XMPP
18:12:06 jonasw like losing messages in groupchats
18:12:21 jonasw they don’t think the issue might be the experimental E2EE implementation they’re using.
18:12:35 jonasw (or, maybe worse, blaming it on the server)
18:12:55 Ge0rG moparisthebest: OMEMO failed to address the device migration use case, among others.
18:13:28 Ge0rG moparisthebest: my position is: XMPP is already f***ing complicated and has too many corner cases that break the UX. We shouldn't be adding yet another one.
18:14:20 Flow uh Ge0rG droped the E2EE bomb
18:14:43 Flow where is my popcorn? ☺
18:15:12 Flow Ge0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly
18:15:23 stefandxm has joined
18:15:25 Ge0rG Flow: what bomb? I'm making this points for years now.
18:16:28 Flow Ge0rG: well I know, but obviously there are still people who act a little bit shocked when you say that
18:17:10 moparisthebest your arguments all apply to OTR
18:17:17 moparisthebest not at all to PGP
18:17:22 moparisthebest and only a little bit to OMEMO
18:17:24 moparisthebest so
18:17:26 Ge0rG Flow: I'm sure it's possible to make E2EE more user-friendly than it is now. However, it won't be as polished as WhatsApp E2EE any time soon, and we (as the Jabber community) already lack the resource to make XMPP more user-friendly.
18:18:16 Ge0rG moparisthebest: my arguments apply to all E2EE on top of XMPP
18:18:56 moparisthebest also Ge0rG your argument was if you want privacy have all your friends have an account on your server? kind of kills federation no?
18:19:25 Valerian has joined
18:19:42 Flow moparisthebest: surely the problem isn't E2EE *on* XMPP
18:20:02 Flow moparisthebest: no, he (and I) want you to run your own XMPP service
18:20:13 Flow and federate with your the XMPP server that is run by your friends
18:20:30 moparisthebest so every user runs their own server?
18:20:37 Holger moparisthebest: "not at all to PGP" -- no matter what E2EE you're using, you either don't verify keys or break communication by insisting on verified keys.
18:20:43 Flow We need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at
18:21:02 Holger moparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.
18:21:15 Holger moparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.
18:21:32 Flow And to achieve that, we need to enable non-tech savy users to run their XMPP server on a vServer or on their home router
18:21:45 Flow under their own domain
18:22:25 jonasw Holger, incorrect, WhatsApp does server-side spam filtering only with metadata.
18:22:27 Flow Holger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start
18:22:31 emxp has joined
18:22:35 moparisthebest Holger, as Ge0rG said you have metadata, most filtering is on that anyhow?
18:22:51 jonasw moparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata
18:23:02 moparisthebest in fact all the current 'must be on roster' filtering works with e2e
18:23:03 jonasw (well, it’s not exactly like that, but federation makes it so much more difficult)
18:23:11 jonasw must-be-on-roster is a very very bad spam filter
18:23:39 Flow yep, bad idea
18:23:51 lumi has joined
18:24:03 moparisthebest I agree
18:24:15 Holger jonasw, moparisthebest: I doubt that filtering purely on metadata can get you an accuracy anywhere near to filters that also take the body into account.
18:24:18 emxp has joined
18:24:20 emxp has joined
18:24:56 moparisthebest saying e2e is a bit hard so we shouldn't support it is dumb though, it's perfectly legitimate and if done right basically free
18:24:59 Holger Flow: It'll start once OX is ubiquitous of course :-)
18:25:11 Flow hehe
18:25:25 Flow sadly new clients still implement xep27 ;(
18:26:03 Holger moparisthebest: Yeah, dumb. In practice people just give up this XMPP shit due to the E2EE breakage we introduce.
18:26:28 Holger (I've seen *two* people saying just that *today*.)
18:26:38 moparisthebest it's better than nothing (xep27)
18:27:17 Flow moparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all
18:27:21 Flow for example
18:27:43 moparisthebest replay is a type of attack, sometimes it doesn't matter
18:28:04 Flow ?
18:29:01 jonasw Holger, whatsapp apperently does it quite well
18:29:11 jonasw but I only heard that second- or third-hand
18:29:48 moparisthebest Flow, sometimes you just need to protect content and don't care about replay
18:30:03 jonasw moparisthebest, I don’t say we shouldn’t support e2ee at all. but Jabber as an IM system has much worse problems than not supporting E2EE currently.
18:30:10 jonasw we need to solve those firts
18:30:21 moparisthebest it's always going to have problems, everything does
18:30:35 jonasw *especially* with security systems you can’t simply handwave problems away
18:30:35 Flow moparisthebest: but especially in IM you want to know that the "I aggree" from the other side was a current response, and not from days ago
18:30:43 jonasw people don’t expect replay attacks to work
18:30:48 Holger jonasw: Yes much better than we do, mostly because they hide verification very well and don't have MAM/multi-device support. (And of course because they avoid implementation issues by controlling the clients.)
18:30:52 jonasw and you can’t expect people to understand that
18:31:14 jonasw Holger, they don’t have multi-device support?
18:31:16 jonasw I thought they did.
18:31:21 jonasw but how does that relate to spam filtering?
18:31:35 Holger jonasw: No, they just have a web client that talks to your phone.
18:31:57 jonasw eww
18:32:27 mimi89999 has joined
18:32:55 stefandxm has left
18:33:55 zinid has left
18:37:14 moparisthebest Flow, yes the "I agree" replay is potentially a problem, the "here is your report for 2017-01-01 08:32 bla bla bla" is not
18:37:48 moparisthebest but uh, "replay" is also a huge problem without e2e, so
18:43:04 jjrh has left
18:44:35 jjrh has left
18:46:54 zinid has left
18:48:47 jjrh has left
18:55:28 zinid has left
18:56:32 Ge0rG has left
18:58:43 pep. has joined
19:10:43 Ge0rG Holger: and because they have millions of dev budget.
19:16:05 Ge0rG has left
19:17:29 Flow moparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?
19:18:00 moparisthebest Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess
19:18:41 Holger Ge0rG: RIght.
19:18:53 moparisthebest what is the argument here? xep27 is bad because it's vulnerable to replay so use no encryption? (which is also vulnerable to replay)
19:19:39 Holger That's not my argument, no. I use 0027 with the two-and-a-half geeks that manage to cope with key deployment in my roster myself.
19:19:57 moparisthebest anecdote of course but I switched to xmpp specifically so I could use PGP, then omemo came along and I use it sometimes, PGP still has a place
19:20:54 moparisthebest now I'd much rather use OX than 27, but 27 is better than nothing
19:20:59 Flow moparisthebest: The point is that xep27 is badly designed, allowing for replay attacks because the recipient (and a timestamp) is not part of the secured data
19:21:09 Ge0rG moparisthebest [21:22]: > Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess And if the report author gets a "the report is okay, publish it", you can't know for sure
19:21:23 Holger moparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.
19:21:43 moparisthebest right I completely agree OX is better Flow , but 27 is better than nothing
19:21:45 Flow OpenPGP certainly has it's place
19:22:16 Flow moparisthebest; And that is where I disagree with you ☺
19:22:22 moparisthebest I find it most handy for where I used to send cronjob output as pgp encrypted email from my servers
19:22:39 moparisthebest a sendxmpp that does OMEMO seems, hard
19:22:47 Flow true
19:23:27 moparisthebest Flow, how could 27 possibly be worse than no encryption exactly
19:23:40 moparisthebest it doesn't prevent replay or spoofing, neither does no encryption
19:23:40 Holger Wrong sense of security.
19:23:45 Flow moparisthebest: what holger said
19:23:46 moparisthebest it does protect content
19:23:53 moparisthebest that's all it does, I know that, I'm fine with that
19:24:01 Flow it may be sufficently secure for the use case you described
19:24:05 Flow but not for the gernal IM use case
19:24:52 moparisthebest 100% agree OX should be pushed forward and I will drop 27 first :P but until then
19:24:56 Flow OX would be able to prevent spoofing, xep27 is not
19:25:26 Flow It's such a pitty that there is no high level OpenPGP library for java
19:25:51 moparisthebest you could do android first :)
19:26:03 moparisthebest in fact there was a WIP OX pull request for conversations
19:26:04 Flow (Java/Android that is)
19:26:17 moparisthebest android has an excellent openpgp implementation/app
19:26:46 Flow I know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015
19:26:50 Flow *met
19:27:37 Flow I've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android
19:28:00 moparisthebest on android at least it's better as-is isn't it?
19:28:32 moparisthebest as a PGP app that's usable by other apps
19:28:34 Flow I'm sorry, I don't know how to parse that
19:28:45 Flow Ahh yes, that was our idea for the conversations OX implemenation
19:28:56 moparisthebest I don't want to import my key into conversations, and k9mail, and oandbackup
19:29:11 moparisthebest I instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it
19:29:15 Flow OK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations
19:29:19 Flow but the effort stalled
19:29:23 Holger moparisthebest: I don't want to import any keys anywhere.
19:29:28 zinid > incorrect, WhatsApp does server-side spam filtering only with metadata. No surprise, for centralized servers it's much easier to fight against spam when you control *every* user
19:30:22 Holger moparisthebest: The key should silently be created by the app I'm using and auto-deployed to any other devices. Anything else will end up being completely unusable.
19:30:22 moparisthebest oh well that's a different thing, yea I'm sure they'd add additional apis
19:30:32 moparisthebest Holger, omemo?
19:30:39 Holger moparisthebest: OX, maybe.
19:31:14 Holger moparisthebest: https://xmpp.org/extensions/xep-0373.html#synchro-pep
19:31:17 moparisthebest hmm I'm not sure 1 key being automagically distributed is better than one key per device
19:31:38 moparisthebest yea I remember reading it, I'm not convinced I want my encrypted key on my server
19:31:54 Holger moparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.
19:32:25 Holger moparisthebest: Do you have a single non-geek in your roster you're talking PGP to?
19:32:25 moparisthebest I think you are right actually
19:32:33 moparisthebest in that the normal case it should do that
19:32:44 moparisthebest but should also allow me to use my already-set-up-not-on-server key
19:33:08 moparisthebest Holger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)
19:33:09 Holger Yah I'm not discussing Advanced -> Expert -> Special options.
19:33:22 jere has joined
19:33:46 moparisthebest do I have anyone in my roster I talk to with PGP that I didn't fully set up their key manually for them for? no :'(
19:34:19 Holger I had like five and am down to three I think.
19:34:31 Holger Of my ~150 contacts.
19:34:37 Holger If which 100+ are geeks :-)
19:34:42 Holger s/If/Of
19:35:39 moparisthebest what client(s) do you use?
19:35:53 Holger MCabber and Conversations.
19:37:12 moparisthebest ah ok, I started with gajim and it didn't actually do carbons+pgp right, I got the impression no one else had tried
19:38:01 Holger I heard of various issues with Gajim's PGP support but never tried myself.
19:38:08 Holger Works just fine with my two clients.
19:38:46 moparisthebest I put in a patch to fix that and it worked great for years until new gpg broke the python gpg lib, and I haven't looked at it
19:40:09 Holger Ah right gpg2 is a PITA for MCabber as well. The fix is sticking to gpg1.
19:41:12 Holger (Though McKael is somehow using gpg2 I think ...)
19:42:43 jere has joined
19:42:46 moparisthebest iirc it worked fine with gpg 2 but 2.1 broke it
19:43:11 moparisthebest I think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything
19:43:18 moparisthebest I need to look into it one day
19:44:05 zinid I'm not a security expert, but what is a problem to keep private key securely on a server?
19:44:24 McKael Holger: Yes I'm using GPG2 but it's painful, indeed.
19:45:07 moparisthebest McKael, have any patches laying about or a terrible wrapper script or what? :)
19:45:21 zinid can't I just encrypt it using my password which is supposedly stored hashed as well?
19:46:34 McKael moparisthebest: No, lately I've been using the default pinentry and it messes things up
19:47:09 McKael Not sure how I got rid of that before, I forgot :/
19:47:10 jubalh has left
19:48:18 Wiktor zinid: defense in depth, one can tell that your server is already protected by password so no need for PGP private key passwords, but you use it anyway to have layers of protection
19:49:15 zinid I don't understand, according to e2e proponents, they don't trust server admins
19:49:35 Holger zinid: Yes that's how I'd do it. Not sure how to survive forgotton/restored passwords though. Maybe each client needs an unencrypted copy of the key to re-encrypt it on password change or something ...
19:50:21 tim@boese-ban.de has joined
19:51:18 Wiktor zinid: you don't store the private key even encrypted because loss of password would compromise the key
19:51:21 zinid has left
19:51:35 Wiktor I'm not using PGP with xmpp though
19:51:36 mimi89999 has joined
19:51:53 Wiktor But usually you don't even store the private key in software but use hardware token
19:51:53 daniel has joined
19:51:58 Wiktor To further protect the key
19:52:01 zinid but you can also lose private key
19:52:04 Holger "usually" :-)
19:52:18 zinid Holger: lol :)
19:52:38 matlag Holger, I would separate the account's PW from the key's encryption PW, then the server also stores the latest modif of the encryption PW, when the user connects, the client checks if its stored PW is the latest, and if not prompt the user for the new one
19:52:40 zinid and typically you lose private key with losing phone for example
19:52:54 zinid still not clear
19:53:56 zinid I cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)
19:54:00 Holger matlag: The server has a clear-text copy of the key encryption PW??
19:54:09 matlag no, only the date of the latest change
19:54:12 Holger Ah.
19:54:22 Holger So simply a separate passphrase?
19:54:38 matlag yep
19:54:57 Holger "Hello User, please type your password! ... thanks, now please type your other password!"
19:55:00 zinid which will be the same for the majority of users :)
19:55:00 Holger They'll love you.
19:55:02 Wiktor zinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card
19:55:28 Wiktor Note I'm not advocating for that
19:55:29 zinid Wiktor: are we building a network for trully paranoid?
19:55:36 zinid Wiktor: can we just have non-paranoid mode/
19:55:37 zinid ?
19:55:38 matlag well, currently the risk is "Hello User, please type your password! ... now please type your entire private key"
19:56:09 Wiktor I'm not building anything just saying there are various threat models in existence
19:56:20 matlag zinid, you need to fit all the needs! so paranoid should be an option
19:56:46 zinid matlag: sure, don't store private keys on server, keep them on hardwared device
19:57:02 zinid I mean it's totally opaque for the server where you keep your keys
19:58:04 Holger matlag: My point was about increasing the usablity of E2EE, not about increasing it's security. The latter is easier, the problem is just that you end up with zero users of your secure solution.
19:58:15 zinid but still a problem with password restoration indeed
19:59:22 Holger matlag: As a well-hidden *option* you can make it as secure and unusable as you like. The interesting part to achieve is to implement a default behavior that doesn't break day-to-day communication.
20:00:08 zinid I agreed
20:00:19 matlag I admit it's not so friendly, but on the other hand, you can store the key PW on the client and then you don't need to change it as long as you don't change the key PW
20:00:23 zinid currently users are trying to use OMEMO, they fail and resort not to using OMEMO at all
20:01:01 zinid so probably better to use less secure option?
20:01:03 matlag I mean: is that so much more cumbersome than changing your home's wifi password?
20:01:35 Holger zinid: They resort to ditching the non-working XMPP crap.
20:02:05 Holger matlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.
20:02:12 zinid matlag: did you really contact with a regular user? my wife's mother cannot configure wifi for example, but she loves whatsapp, so a potential user
20:02:38 matlag Yeah, ok, point taken
20:04:15 moparisthebest what if you make them have 16 character passwords and take the first 8 for the key password and send the second 8 to the server for login
20:04:39 moparisthebest either way yea I want to decrypt my pgp key with a seperate password, normal users probably don't need it encrypted on the device at all
20:04:59 zinid but all 16 characters will be lost?
20:05:06 Holger moparisthebest: Won't help much if you're trying to protect against the case where the password is lost.
20:05:08 zinid because they are stored in a single place, no?
20:05:11 matlag moparisthebest, They end up typing the 16 characters and that's the same as having hte same PW for both
20:05:13 Flow has left
20:05:13 Holger (zinid was faster.)
20:05:22 Ge0rG What would be great is an xmpp server that encrypts everything for a user with a key pair where the private key is only unlocked while the user is logged in.
20:07:14 Wiktor If your target user is a mother in law you shouldn't be talking about encryption because she probably doesn't care if whatsapp is encrypted but of easy contact discovery and on boarding process
20:07:39 zinid Wiktor: but usually I'm not talking about e2e :)
20:07:48 zinid I think it's still just a toy
20:07:55 moparisthebest Ge0rG, meh that's still just fully trusting the server
20:08:16 moparisthebest I mean you already have full disk encryption and such on the server
20:08:22 Holger Wiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.
20:08:27 Zash Ge0rG: Wanna the crypto design and audit?
20:08:28 Wiktor zinid: agreed, but for me it's a toy for power users, like PGP itself
20:08:31 matlag So let's assume most users don't care about encryption but you want a default encryption for them: most can use the same PW for account and private key, others can have them separated?
20:09:08 moparisthebest or just don't have a password on the local pgp key
20:09:16 Holger Wiktor: So I'm getting to think about how to enable E2EE in order to make the geek marketing department happy without breaking stuff for the mother in law :-)
20:09:17 zinid Wiktor: then nothing should be changed, everything is great
20:09:19 moparisthebest it's storing full conversations in plain text anyway, most likely
20:09:30 Wiktor Holger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted
20:09:37 Wiktor For me that's a good ratio
20:09:54 Holger Wiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.
20:10:18 Wiktor zinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices
20:10:19 Zash I did a prototype of a thing where some data is encrypted using a key derived from a SCRAM thing that you only have during login
20:10:20 Ge0rG Zash: maybe one day I'll find a corporate customer that will pay for it
20:10:26 moparisthebest because default is how it stays 99% of the time
20:10:30 Ge0rG Zash: I remember that, yeah
20:10:52 moparisthebest and if we've learned anything over the past 5 years or whatever, encryption should always be default
20:11:00 moparisthebest at least, most people have learned that
20:11:02 Holger Wiktor: ^ see?
20:11:19 zinid :D
20:11:21 Wiktor Hshshw
20:11:24 Holger Wiktor: So how to deal with all the moparisthebests in the community? :-)
20:11:26 Wiktor Hahaha*
20:11:29 Zash moparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.
20:11:31 moparisthebest :)
20:11:40 Wiktor Great point Holger
20:12:04 moparisthebest Zash, do you know of better ones that don't eat battery due to p2p ?
20:12:07 Zash XMPP is a giant compromise. Compromise between p2p and centralized.
20:12:12 SamWhited > encryption should always be default Define "encryption"? Are you still talking about e2e encryption like most of this conversation (I've just been passively following)
20:12:24 moparisthebest all of it, imho
20:12:45 moparisthebest I mean, TLS/transport encryption should be mandatory with no cut-off
20:13:03 Wiktor moparisthebest: well it is on xmpp since 2014?
20:13:09 moparisthebest e2e should be default, with the ideal of no cut-off
20:13:23 Holger moparisthebest: Apart from that, I should be rich!
20:13:43 moparisthebest that's the ideal isn't it? :P
20:14:40 daniel has left
20:15:16 Wiktor moparisthebest: what is your threat model? Why do you want e2e6by default? Do you understand that without face to face fingerprint comparisons e2e does not provide any significant advantages?
20:15:34 moparisthebest I tend to agree current pgp/omemo isn't quite ready for default enforced prime-time, that's just where we should be aiming
20:16:00 moparisthebest Wiktor, it still defeats passive surveillance which is ubiquitous
20:16:16 Wiktor Tls defeats passive surveillance
20:16:16 moparisthebest also all the server hack leaks everywhere
20:16:24 stefandxm has joined
20:16:32 SamWhited Why? What is the actual thing you are trying to accomplish by making e2e encryption the default?
20:16:50 Zash moparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed
20:17:29 moparisthebest you don't have to trust your server, so why trust your server
20:17:40 moparisthebest and, your chat partner's server if not the same
20:17:41 zinid Zash: the point I'm told is that the remote server can be evil and you can do nothing with it
20:17:54 Wiktor Zash: exactly. moparisthebest If your server lies about your keys and you don't compare them live then the security model has been broken
20:18:11 Valerian has left
20:18:16 moparisthebest also define 'screwed', it can block your messages, it can't do anything else with e2e
20:18:28 moparisthebest Wiktor, again an active attack that you can detect before, during, or after
20:18:30 Zash zinid: Sure, you have to trust that your chat partner picked a trustworthy server too.
20:18:43 moparisthebest vs you having no idea who has your messages when
20:19:48 Wiktor Well usually only your server and your friend's has messages, in xmpp they are directly connected.
20:19:58 zinid Zash: I agree you cannot build security without trust, the question is how paranoid we should be
20:20:08 SamWhited It sounds like "encryption" is being equated with "security" here, and that's always dangerous. If you ignore the user aspect (you're making all sorts of trade offs by forcing everything to be e2e encrypted) they'll just go somewhere else or develop bad habits that make things worse. If you can't clearly articulate a reason other than "why not?" you may want to think about it more. That's never an okay way to approach thinking about security.
20:20:29 moparisthebest Wiktor, do I know if they are connected securely
20:20:43 Valerian has joined
20:20:50 moparisthebest do I know if the other users server mandates encryption on c2s
20:21:03 moparisthebest tls in this case
20:21:04 Wiktor Well your server should mandate your security standards
20:21:27 moparisthebest but if you sign up for newhotserver.im
20:21:36 moparisthebest you think key verification is the problem
20:21:38 waqas has left
20:21:43 moparisthebest but the solution is to personally trust your server operator?
20:21:46 moparisthebest seems suspicious
20:21:50 Wiktor Then do you know if your friends computer is not compromised by malware?
20:22:10 moparisthebest it's about minimizing risk, that's a risk either way
20:22:17 moparisthebest you have to trust your friend's endpoint
20:22:24 moparisthebest you don't have to trust everything in between
20:22:24 Wiktor Key verification is always the biggest problems :)
20:23:06 Wiktor Yes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere
20:23:29 SamWhited Or if it actually makes things worse…
20:23:43 moparisthebest what if it doesn't have any disadvantages
20:23:51 Wiktor Yes, exactly. There are always trade offs
20:24:03 zinid moparisthebest: but it does
20:24:15 moparisthebest you mean some current systems do
20:24:25 zinid yes
20:25:19 Wiktor > what if it doesn't have any disadvantages I've never seen a solution to anything without disadvantages. There are always constraints.
20:25:33 Valerian has left
20:25:35 zinid and security is always inversly proportional to usability
20:26:08 zinid whatever encryption you suggest, you lower the usability part
20:26:38 zinid so users should clearyl understand why they suffer
20:26:38 moparisthebest that's not true though
20:26:45 moparisthebest do you have your laptop hard drive encrypted?
20:27:20 zinid moparisthebest: that's not even my words, Schneier said that :)
20:27:35 zinid moparisthebest: no, I don't
20:27:39 moparisthebest even great guys can be wrong sometimes haha
20:27:59 moparisthebest ok well that's just inexcusable why? :P
20:28:09 moparisthebest I guess if it never leaves your house it's probably fine
20:28:14 zinid moparisthebest: I don't know how to do this
20:28:16 Wiktor HD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)
20:28:21 zinid is it ok answer? :)
20:28:58 matlag moparisthebest, In this case, for example, the only way to have a solution that guarantees no user intervention is to have the private key stored on server and encrypted with the user's account PW: no degradation of usability, BUT: not nearly as safe as the blows and whistle you hear for great E2E
20:28:59 moparisthebest the point I was going to make was it's the same either way, you type a password to get into it regardless, and nowadays it doesn't even run slower
20:29:06 SamWhited I have two laptops, one has the disk encrypted and one doesn't. The one with the disk encrypted I have to type a password in every time I boot and if the sector that contains the key gets corrupt the whole harddrive is lost instead of just that one sector.
20:29:08 SamWhited That is a trade off.
20:29:22 SamWhited I only chose to make it on one laptop because I have a very specific threat I am trying to protect against with that specific machine.
20:29:27 matlag if you increase security, then you need the user intervention, and as you increase it, more and more user intervention
20:29:30 moparisthebest a few sectors include the key normally SamWhited
20:30:22 SamWhited Doesn't matter, it is more likely that I lose all the data (I do actually have it in two key slots, I also keep an offsite backup, another tradeoff I made)
20:30:26 goffi has left
20:30:47 SamWhited The point is there are tradeoffs to the thing you used as an example too. If you don't even know what threat you're trying to protect against, there's little point in making some of these trade offs.
20:30:54 moparisthebest really that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway
20:31:08 moparisthebest so if they forget their password and don't have logs from yesterday, oh well
20:31:20 moparisthebest I guess it's a trade off but also maybe what they expect?
20:31:24 zinid a good example is probably how PKIX is used currently in browsers
20:31:36 moparisthebest (I'm basing this on all the users that want to be able to delete shared pictures from http upload)
20:31:37 Ge0rG I expect IM history to be eternal. Maybe I'm different.
20:31:39 zinid very little inconvenience
20:32:10 moparisthebest Ge0rG, then you already have backups and such and will get that with e2e also
20:32:19 efrit has joined
20:32:55 Ge0rG moparisthebest: e2ee is more complicated than not having it.
20:33:19 Ge0rG moparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.
20:33:19 stefandxm has left
20:34:16 Ge0rG And I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.
20:34:22 moparisthebest I guess everything is more complicated than not having it
20:34:36 Ge0rG moparisthebest: Easy XMPP is an exception
20:35:18 zinid xmpp2 !!!111
20:35:18 moparisthebest still more code
20:35:36 lovetox has joined
20:36:20 zinid Ge0rG: btw, your subject about message routing didn't route further in the standards@ :)
20:36:34 zinid Ge0rG: my guess is that nobody knows how to fix stuff, lol
20:37:00 waqas has joined
20:37:14 moparisthebest can we make direct tls the only way to connect in xmpp2 ? :P
20:37:16 zinid adding more xeps => sucks breaking compatiblity => sucks
20:38:10 zinid moparisthebest: is it the major problem? :)
20:38:24 moparisthebest no just another nice-to-have
20:38:59 moparisthebest also I don't see any trade-offs with this one haha
20:40:54 la|r|ma has joined
20:40:55 lskdjf has joined
20:42:42 zinid the trade-off is more implementation
20:42:59 zinid poor library support
20:43:05 moparisthebest for direct TLS ?
20:43:08 moparisthebest surely it's the opposite
20:43:10 zinid yes
20:43:31 moparisthebest every TLS lib ever vs xmpp-specific-libs ?
20:43:32 zinid you need to support SNI in server, that's some work if you use openssl ;)
20:44:08 zinid ejabberd doesn't support it for this reason, the API is ugly as hell
20:44:14 moparisthebest you are already doing far more work for everything else in xmpp2 surely
20:44:19 zinid I need to be a man and implement it
20:44:28 moparisthebest anyway it gives you tons of other advantages
20:44:40 moparisthebest 0-rtt, false start, everything fancy https gets
20:45:13 zinid isn't this the trade-off we're talking about? :)
20:45:49 zinid you get all these goods, but need to put more code, at least server side
20:46:20 zinid and ALPN is only supported in openssl 1.0.2, some systems still don't have it yet
20:46:23 moparisthebest you are talking about xmpp2 though, it's all more code
20:46:55 MattJ I think I'd rather rewrite everything XMPP from scratch than spend time near OpenSSL's API again
20:46:57 zinid moparisthebest: that was a joke actually :) obviously transition to xmpp2 will bring lots of pain
20:47:36 moparisthebest also zinid 1.0.1 is already dead so I don't think anyone should care, hopefully :(
20:47:46 moparisthebest yea openssl is the perfect example of a footgun api
20:48:24 zinid moparisthebest: surprisingly, we get complains from time to time about cutting edge version requirement (1.0.1), lol :)
20:48:56 Holger "zinid 1.0.1 is already dead"
20:49:03 zinid ah
20:49:05 Holger goes updating zinid.
20:49:17 zinid2.0 has joined
20:49:28 zinid_2.0 has joined
20:50:54 moparisthebest context, it's all about context :P
20:51:19 Ge0rG has left
20:52:37 Valerian has joined
20:54:10 zinid but still I think direct tls is a great idea
20:54:50 stefandxm has joined
21:13:50 Guus has left
21:17:50 tim@boese-ban.de has joined
21:21:20 waqas has left
21:21:31 Tobias has joined
21:26:38 jjrh has left
21:42:52 jubalh has joined
21:43:28 Alex has left
21:45:09 jubalh has left
21:48:00 moparisthebest has joined
21:49:51 winfried has joined
21:51:02 intosi has joined
21:51:15 jubalh has joined
21:51:21 andrey.g has joined
21:51:38 uc has joined
21:53:50 SamWhited has left
21:57:23 ralphm has joined
22:02:28 andrey.g has joined
22:05:49 andrey.g has left
22:06:05 waqas has joined
22:08:55 Valerian has left
22:11:18 jubalh has left
22:11:18 la|r|ma has joined
22:12:37 lskdjf has joined
22:14:27 jubalh has left
22:22:34 andrey.g has joined
22:32:00 winfried has joined
22:33:10 jjrh has left
22:35:02 andrey.g has joined
22:42:37 Valerian has joined
22:44:27 uc has joined
22:44:30 Tobias has joined
22:49:29 zinid has left
22:49:38 andrey.g has joined
22:49:51 jjrh has left
22:52:57 andrey.g has left
22:56:43 la|r|ma has joined
22:56:47 zinid has left
22:56:51 zinid has joined
22:56:55 zinid has left
22:57:07 matlag has left
22:57:26 lskdjf has joined
23:00:09 zinid has joined
23:07:51 jjrh has left
23:11:25 jjrh has left
23:12:04 Valerian has left
23:17:15 Valerian has joined
23:21:46 Zash has left
23:27:55 waqas has left
23:28:56 ThurahT has left
23:29:05 lovetox has left
23:29:10 ThurahT has joined
23:34:17 ThurahT has left
23:42:45 waqas has joined
23:44:05 ThurahT has joined
23:57:32 Guus has left