XSF Discussion - 2022-02-21

  1. fhtest has left
  2. matkor has left
  3. karoshi has left
  4. lskdjf has left
  5. gooya has left
  6. restive_monk has joined
  7. neshtaxmpp has left
  8. neshtaxmpp has joined
  9. kinetik has joined
  10. alacer has left
  11. stp has left
  12. debacle has left
  13. Vidak has left
  14. kinetik Hi, I'm curious if there's an XEP out there that deals with a tree-like structure for conversations, where each response is either root level or is in response to some other message
  15. sabry has left
  16. neshtaxmpp has left
  17. neshtaxmpp has joined
  18. kinetik (sort of like how reddit structures things, but without all the other stuff)
  19. BASSGOD has left
  20. millesimus has left
  21. restive_monk has left
  22. sabry has joined
  23. Sam It's built into the RFC, but nothing uses it as far as I know: https://datatracker.ietf.org/doc/html/rfc6121#section-5.2.5
  24. millesimus has joined
  25. andrey.g has joined
  26. Andrzej has joined
  27. restive_monk has joined
  28. sabry has left
  29. sabry has joined
  30. restive_monk has left
  31. jcbrand has joined
  32. adiaholic has joined
  33. restive_monk has joined
  34. restive_monk has left
  35. matkor has joined
  36. jcbrand has left
  37. restive_monk has joined
  38. adiaholic has left
  39. qwestion has joined
  40. emus has left
  41. alacer has joined
  42. stp has joined
  43. Vidak has joined
  44. adiaholic has joined
  45. Andrzej has left
  46. BASSGOD has joined
  47. matkor has left
  48. andrey.g has left
  49. tykayn has left
  50. stp has left
  51. alacer has left
  52. Vidak has left
  53. adiaholic has left
  54. matkor has joined
  55. alacer has joined
  56. adiaholic has joined
  57. adiaholic has left
  58. Matthew (away) has left
  59. homebeach has left
  60. Rixon ๐Ÿ‘๐Ÿ—จ has left
  61. uhoreg has left
  62. Half-Shot has left
  63. Half-Shot has joined
  64. Matthew (away) has joined
  65. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  66. uhoreg has joined
  67. homebeach has joined
  68. Andrzej has joined
  69. adiaholic has joined
  70. argentum has left
  71. wladmis has left
  72. Friendly Resident Cynic has left
  73. daags has joined
  74. qwestion has left
  75. Andrzej has left
  76. matkor has left
  77. matkor has joined
  78. Friendly Resident Cynic has joined
  79. Andrzej has joined
  80. qwe has joined
  81. Yagiza has joined
  82. Andrzej has left
  83. Calvin has joined
  84. qwe has left
  85. marc0s has left
  86. marc0s has joined
  87. floretta has left
  88. floretta has joined
  89. adiaholic has left
  90. Menel has joined
  91. adiaholic has joined
  92. Titi has joined
  93. millesimus has left
  94. mimi89999 has left
  95. mimi89999 has joined
  96. eevvoor has left
  97. alacer has left
  98. eevvoor has joined
  99. xnamed has left
  100. Seve has joined
  101. pete has left
  102. Andrzej has joined
  103. millesimus has joined
  104. paul has joined
  105. Tobias has joined
  106. Titi has left
  107. floretta has left
  108. floretta has joined
  109. adiaholic has left
  110. adiaholic has joined
  111. adiaholic has left
  112. adiaholic has joined
  113. Titi has joined
  114. me9 has joined
  115. msavoritias has joined
  116. ti_gj06 has joined
  117. Vidak has joined
  118. chronosx88 has joined
  119. wurstsalat has joined
  120. ti_gj06 has left
  121. ti_gj06 has joined
  122. me9 has left
  123. Andrzej has left
  124. Vidak has left
  125. sabry has left
  126. chronosx88 has left
  127. chronosx88 has joined
  128. jcbrand has joined
  129. millesimus has left
  130. Paganini has left
  131. millesimus has joined
  132. Vidak has joined
  133. sabry has joined
  134. Vidak has left
  135. Vidak has joined
  136. marc has joined
  137. Guus has left
  138. Guus has joined
  139. Menel has left
  140. ti_gj06 has left
  141. sabry has left
  142. ti_gj06 has joined
  143. xnamed has joined
  144. goffi has joined
  145. xnamed has left
  146. debacle has joined
  147. Mikaela has joined
  148. marc has left
  149. marc has joined
  150. emus has joined
  151. eab has left
  152. eab has joined
  153. norkki has left
  154. Seve has left
  155. Andrzej has joined
  156. millesimus has left
  157. norkki has joined
  158. rion Interesting. I didn't know it's there but always missed that thing after slack. Definitely something worthing to implement
  159. Seve has joined
  160. adiaholic has left
  161. fhtest has joined
  162. adiaholic has joined
  163. Link Mauve Some clients use it, I know of at least Movim.
  164. adiaholic has left
  165. adiaholic has joined
  166. MattJ The problem with threading is not really the protocol, but the UI
  167. millesimus has joined
  168. Kev Just relying on thread doesn't work very well (like so many things) unless you have complete knowledge, though,.
  169. Kev Another thing we could really do with MAM understanding.
  170. wladmis has joined
  171. Andrzej has left
  172. Matthew (away) has left
  173. homebeach has left
  174. Rixon ๐Ÿ‘๐Ÿ—จ has left
  175. uhoreg has left
  176. Half-Shot has left
  177. Half-Shot has joined
  178. Matthew (away) has joined
  179. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  180. uhoreg has joined
  181. homebeach has joined
  182. Tobias Or have MAM support a thread query filter.
  183. Kev That would be MAM understanding threads :)
  184. millesimus has left
  185. xnamed has joined
  186. Tobias Kind of. Can't you already query for other properties like addresses or body text?
  187. Zash Implementation-dependent
  188. Zash Not mandated by XEP-0313
  189. Tobias True
  190. Zash The basic set of fields are all derived from insertion into the archive (archive-id, timestamp, with=to|from depending on direction), not properties of the stanza itself
  191. Tobias But technically not all that complex to allow querying for stanza properties, considering it ends up in some kind of database anyway.
  192. Andrzej has joined
  193. Zash You probably want to have some index over the things you query on
  194. Zash Should be doable too of course
  195. Tobias True
  196. Dele Olajide has joined
  197. marc has left
  198. marc has joined
  199. APach has left
  200. pasdesushi has joined
  201. adiaholic has left
  202. chronosx88 has left
  203. Kev Querying for a hierarchy of thread references would probably not be a very enjoyable SQL statement to write (or whatever).
  204. adiaholic has joined
  205. Andrzej has left
  206. Dele Olajide has left
  207. adiaholic has left
  208. adiaholic has joined
  209. millesimus has joined
  210. wladmis has left
  211. wladmis has joined
  212. xnamed has left
  213. adiaholic has left
  214. mjk has joined
  215. adiaholic has joined
  216. Matthew (away) has left
  217. Rixon ๐Ÿ‘๐Ÿ—จ has left
  218. homebeach has left
  219. uhoreg has left
  220. Half-Shot has left
  221. Half-Shot has joined
  222. Matthew (away) has joined
  223. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  224. uhoreg has joined
  225. homebeach has joined
  226. Steve Kille has left
  227. Steve Kille has joined
  228. Steve Kille has left
  229. Steve Kille has joined
  230. Steve Kille has left
  231. Steve Kille has joined
  232. sabry has joined
  233. fhtest has left
  234. fhtest has joined
  235. stp has joined
  236. millesimus has left
  237. chronosx88 has joined
  238. restive_monk has left
  239. karoshi has joined
  240. tykayn has joined
  241. gooya has joined
  242. Andrzej has joined
  243. Vidak has left
  244. restive_monk has joined
  245. neshtaxmpp has left
  246. Vidak has joined
  247. adiaholic has left
  248. millesimus has joined
  249. fhtest has left
  250. lskdjf has joined
  251. Andrzej has left
  252. Andrzej has joined
  253. sabry has left
  254. gooya has left
  255. adiaholic has joined
  256. gooya has joined
  257. wladmis has left
  258. wladmis has joined
  259. fhtest has joined
  260. karoshi has left
  261. adiaholic has left
  262. adiaholic has joined
  263. karoshi has joined
  264. Vaulor has left
  265. rafasaurus has left
  266. fhtest has left
  267. sabry has joined
  268. marc has left
  269. marc has joined
  270. Vaulor has joined
  271. millesimus has left
  272. neshtaxmpp has joined
  273. gooya has left
  274. gooya has joined
  275. millesimus has joined
  276. karoshi has left
  277. neshtaxmpp has left
  278. neshtaxmpp has joined
  279. karoshi has joined
  280. ti_gj06 has left
  281. marc0s has left
  282. marc0s has joined
  283. gooya has left
  284. gooya has joined
  285. jgart has left
  286. Friendly Resident Cynic has left
  287. karoshi has left
  288. ti_gj06 has joined
  289. adiaholic has left
  290. adiaholic has joined
  291. BASSGOD has left
  292. lovetox has left
  293. adiaholic has left
  294. lovetox has joined
  295. karoshi has joined
  296. adiaholic has joined
  297. Wojtek has joined
  298. alex11 has left
  299. jcbrand has left
  300. jcbrand has joined
  301. adiaholic has left
  302. adiaholic has joined
  303. huhn has joined
  304. huhn has left
  305. ti_gj06 has left
  306. larma MattJ, I think the thread protocol IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays.
  307. sabry has left
  308. larma MattJ, I think the thread protocol in RFC 6121 IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays.
  309. Kev Howso?
  310. Daniel has left
  311. ti_gj06 has joined
  312. adiaholic has left
  313. larma Threads in Slack and e-Mails is basically something like a collection of replies (including depth with replies to replies in e-Mail). Threads in RFC 6121 is more like a session (with child sessions). For example, if we do a board meeting in this channel, the board meeting could be a thread and each agenda sub items could be a sub-thread.
  314. larma In Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level.
  315. larma In Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level (except for sub-threads, which are largely independent and also fork of a thread, not a specific message of that thread)
  316. adiaholic has joined
  317. Andrzej can't we just use https://xmpp.org/extensions/xep-0372.html#usecase_previous for linking messages and building a tree?
  318. karoshi has left
  319. Daniel has joined
  320. larma Andrzej, 0372 ยง 3.4 is about adding a reference (aka a link) to a previous message where the original message forgot to include the link, not about having your new message reference an old message.
  321. larma > An example of this might be where a MIX channel asynchronously adds information about references made in previous messages by users. In this case the message MUST NOT contain a body.
  322. Andrzej ok, my bad
  323. larma https://xmpp.org/extensions/xep-0461.html would have the correct syntax, but is specifically not meant for creating threads but rather for telegram/whatsapp like replies
  324. larma Because it's close to impossible to build the thread feature in a backwards compatible fashion
  325. rafasaurus has joined
  326. Kev larma: Right, the 'not sending to the channel' thing is Slack/Discord/Guilded/etc.-ish. I'm not convinced the same is true of email - they're all still at the same level logically. My intention with MIX was that threads would go off on their own node within the room.
  327. larma "Best" way is probably to not show the thread to non-supporting clients...
  328. larma "Best" way is probably to not show a thread to non-supporting clients...
  329. karoshi has joined
  330. Kev Probably going to be hard to get agreement on whether best is to flood a non-supporting client or to deny them completely. But I think once you've got a community where threads are in use any fallback is going to suck one way or another.
  331. Kev (I'm pro-threads, BTW, in case that doesn't come across)
  332. millesimus has left
  333. millesimus has joined
  334. larma Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages?
  335. Kev Of course, if you have supporting clients, and you have MAM understanding threads, <thread> is just about enough to get going with.
  336. Kev > Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages? Yes, it's not going to be very satisfying whatever you do there.
  337. larma If you want Slack-like UI, how do you fork a thread off a message that did not carry a <thread> already? RFC 6121 requires the initial message of a thread to already carry a thread id.
  338. Ellenor Malik could message and thread IDs exist in the same namespace, where a thread ID of a message A being the message ID of a message B is illegal?
  339. Menel has joined
  340. Ellenor Malik does a msg ID facility exist?
  341. larma > The value of the <thread/> element MUST uniquely identify the conversation thread either between the conversation partners or more generally
  342. millesimus has left
  343. adiaholic has left
  344. Kev So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :)
  345. MattJ Ellenor Malik: we have at least 4 ways of adding IDs to messages, so I hope we're good on that front :)
  346. wladmis has left
  347. wladmis has joined
  348. Ellenor Malik > Kev wrote: > So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :) I think so.
  349. larma Kev, well, I feel the feature that was standardized isn't exactly what people want.
  350. BASSGOD has joined
  351. Wojtek has left
  352. larma Also the specifications are sometimes very vague
  353. Ellenor Malik The value of the element could be assumed if not specified?
  354. Ellenor Malik The value of the thread element could be assumed if not specified?
  355. wladmis has left
  356. wladmis has joined
  357. BASSGOD has left
  358. larma Also reading XEP-0201 again: > the value of the <thread/> element shall be considered equivalent to a unique identifier for the chat session
  359. Kev larma: I think that's true of a lot of our specs - that they (deliberately) define the protocol, but not how to use it for particular use cases. Whether that's a problem or not probably depends who you ask, but it does mean three people wanted to produce a threads-based system at the moment, they'd probably end up with four logically incompatible systems.
  360. Wojtek has joined
  361. adiaholic has joined
  362. wladmis has left
  363. larma I remember that some client (I think it was Gajim) implemented RFC 6121 threads. All messages in a conversation used the same thread id unless you close the conversation and reopen it. That sounds like what XEP-0201 has in mind, but totally is not what Slack or the likes do.
  364. Wojtek has left
  365. wladmis has joined
  366. wladmis has left
  367. wladmis has joined
  368. larma XEP-0201 even suggests color coding the thread information. I can imagine that to work pretty good (a message in thread A has a red bar inn front of it, a message in thread B a green bar and a message in thread C that is a child of A has a red and a blue bar), but again it's completely different than Slack-like
  369. larma The RFC 6121/XEP-0201 threads seem more similar to the thread concept of Zulip
  370. MattJ And many people absolutely hate Slack's threading
  371. Kev I think using the same thread for a conversation unless you branch off is probably sane, isn't it?
  372. MattJ Which goes back to what I said earlier - it's mostly a UI problem, not a protocol one
  373. Ellenor Malik the new threads could be called chains
  374. Ellenor Malik idk
  375. Kev > And many people absolutely hate Slack's threading I know that's true, but are these people who want a *different* threading model, or just hate threads?
  376. Ellenor Malik i am like, not a standardizer
  377. MattJ Kev, I've seen both camps :)
  378. MattJ e.g. Zulip is crazy about threads, and I know people who love that and hate Slack's implementation
  379. MattJ They're both threading, but very differently done
  380. MattJ And with this being such a subjective feature, I don't see how we can standardize threading across the ecosystem in any particular way
  381. MattJ Unless every client is expected to implement the protocol and UI for every type of threading
  382. MattJ (which is obviously absurd)
  383. Wojtek has joined
  384. Kev How does Zulip do it?
  385. larma MattJ, you can easily do the threading of Zulip in Slack, it just needs discipline. The UI of Zulip is better in enforcing things.
  386. Zash Can't you do all kinds of threads with `<thread/>` already?
  387. larma Kev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic, if you create a new message you have to specify the topic
  388. larma Kev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic as the message you replied to, if you create a new message you have to specify the topic
  389. wladmis has left
  390. larma There is no "root thread" in a channel
  391. wladmis has joined
  392. Zash Just have to pick a style and be consistent. So it's impossible.
  393. millesimus has joined
  394. larma Zash, I guess the problem is that <thread> doesn't really define how to do things. At that makes it IMO useless in a federated environment of different clients.
  395. Matthew (away) has left
  396. homebeach has left
  397. Rixon ๐Ÿ‘๐Ÿ—จ has left
  398. uhoreg has left
  399. Half-Shot has left
  400. Half-Shot has joined
  401. Matthew (away) has joined
  402. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  403. uhoreg has joined
  404. homebeach has joined
  405. Zash Yup
  406. larma There are a few things though that don't work with threads.
  407. wladmis has left
  408. wladmis has joined
  409. larma Or at least not sensible
  410. larma You could just make <thread> behave as <reply-to>, that is, every message creates a new thread and that new thread has the thread id of the message it replied to as a parent thread id. This would allow e-Mail like thread trees (where a message has a parent message and not a thread a parent thread) and Slack-like off-threads. If you want to make it easier, pick your thread id to always be your message id, so you spare one id. Make it even easier and remove the <thread> alltogehter and just have a <parent> that references the message id instead of thread id.
  411. edhelas movim is doing that :)
  412. wladmis has left
  413. wladmis has joined
  414. larma Are you also picking thread id = message id?
  415. Ellenor Malik Thread id = message id would mainly make it easier to search for messages threaded up to a given message id
  416. edhelas no, those are different things afaik
  417. larma Ellenor Malik, it also means you have to handle one id less, we already have a bunch of ids on every message, so not adding another one would be a good idea.
  418. ti_gj06 has left
  419. adiaholic has left
  420. ti_gj06 has joined
  421. wladmis has left
  422. wladmis has joined
  423. adiaholic has joined
  424. millesimus has left
  425. Menel has left
  426. millesimus has joined
  427. xnamed has joined
  428. ti_gj06 has left
  429. Wojtek has left
  430. BASSGOD has joined
  431. ti_gj06 has joined
  432. Wojtek has joined
  433. marc has left
  434. marc has joined
  435. Kev has left
  436. Steve Kille has left
  437. marc has left
  438. Steve Kille has joined
  439. Kev has joined
  440. marc has joined
  441. xnamed has left
  442. marc has left
  443. marc has joined
  444. adiaholic has left
  445. floretta has left
  446. karoshi has left
  447. karoshi has joined
  448. adiaholic has joined
  449. ti_gj06 has left
  450. ti_gj06 has joined
  451. xnamed has joined
  452. chronosx88 has left
  453. chronosx88 has joined
  454. floretta has joined
  455. xnamed has left
  456. marc has left
  457. marc has joined
  458. robertooo has left
  459. robertooo has joined
  460. marc has left
  461. marc has joined
  462. robertooo has left
  463. robertooo has joined
  464. Wojtek has left
  465. harry837374884 has left
  466. harry837374884 has joined
  467. adiaholic has left
  468. marc has left
  469. marc has joined
  470. matkor has left
  471. argentum has joined
  472. matkor has joined
  473. karoshi has left
  474. floretta has left
  475. Paganini has joined
  476. millesimus has left
  477. floretta has joined
  478. sabry has joined
  479. alacer has joined
  480. moparisthebest so I've read https://datatracker.ietf.org/doc/html/rfc7712 and https://xmpp.org/extensions/xep-0344.html but one thing remains unclear: you got server A accepting s2s from server B, server B sends a certificate for sasl external that is not signed by a CA so A doesn't immediatly trust it, is the solution to immediately go for dialback? or has anyone considered using POSH or DANE in this case? I'm thinking it'd be secure to "get all hashes that can be used for that domain" and check that the certificate matches at least one of them, in which case you offer SASL EXTERNAL and never do dialback? cc dwd and Zash since I know they've worked on this, though looks like dwd is not currently here :/
  481. qwe has joined
  482. Calvin has left
  483. Calvin has joined
  484. karoshi has joined
  485. moparisthebest if you squint *real* hard, that's *almost* what is said by https://xmpp.org/extensions/xep-0344.html#samecert including DANE+POSH in the lookup, just skipping the actual connecting step
  486. fhtest has joined
  487. sabry has left
  488. Zash I don't understand the question.
  489. moparisthebest Zash, tl;dr how to authenticate incoming S2S certificate using DANE/POSH without dialback
  490. Zash The implementations I did do all the lookups and use that, yes.
  491. Zash I.e. for DANE it does SRV and then TLSA lookups for each SRV
  492. fhtest has left
  493. fhtest has joined
  494. moparisthebest and just trust the connection if any TLSA record matches ?
  495. Zash Same check as for outgoing, yes.
  496. moparisthebest without actually making outgoing XMPP connections ?
  497. Zash Correct
  498. moparisthebest excellent, that seemed secure and the right thing to do, but it's not actually written down anywhere is it ?
  499. millesimus has joined
  500. Zash I think that's what the DANCE WG is about <https://datatracker.ietf.org/wg/dance/about/>
  501. Zash Unfortunately I don't have the energy for IETF
  502. reimar has joined
  503. moparisthebest ah, indeed that looks right, thanks!
  504. moparisthebest I'd be happy with just a best practices XEP
  505. Zash The Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, like kinda like the backwards OCSP
  506. Zash The Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, kinda like the backwards OCSP
  507. moparisthebest > TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS)
  508. moparisthebest that *might* be what they are after there
  509. Zash Yes
  510. Zash Also, this kind of thing was implemented in Chrome once upon a time! (In the other direction tho)
  511. marc has left
  512. marc has joined
  513. BASSGOD has left
  514. BASSGOD has joined
  515. moparisthebest we also used to have HPKP but that went away too :(
  516. Zash Wasn't that a huge footgun?
  517. fhtest has left
  518. moparisthebest I mean, no more than DANE or DNSSEC in general is I guess ?
  519. Zash As in, didn't it permanently burn the domain if you messed it up?
  520. moparisthebest no, only for the TTL
  521. moparisthebest course if you made the TTL very long, well your bad
  522. Zash I don't remember, what were the recommendations?
  523. millesimus has left
  524. Zash HSTS TTL recommendations tend to be like 6 months or more AFAIK
  525. moparisthebest > Note: These examples use a max-age of two months and include all subdomains. It is advised to verify that this setup will work for your server.
  526. moparisthebest from https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning , and since everyone only looks at the examples... :D
  527. moparisthebest RFC doesn't seem to suggest anything
  528. Zash Maybe I should just shoot myself in the DNSSEC and see how long it takes to recover
  529. Zash Should be on the order of hours
  530. moparisthebest yea you generally don't have a DNS TTL of 2 months
  531. Zash Worst case if someone is trying to mess with you would be a couple of weeks
  532. moparisthebest but both HPKP and DNSSEC/DANE should be the same in regard to breaking your website for however long your TTL says
  533. adiaholic has joined
  534. Zash Relatedly I did a CDS based key rollover and it was painless to the point of boring.
  535. moparisthebest I've only rotated my DNSSEC keys once so far and I don't remember it being a problem but also don't remember details
  536. Zash As in, publish new keys and delegation records and the parent zone picks them up.
  537. alacer has left
  538. Matthew (away) has left
  539. uhoreg has left
  540. Rixon ๐Ÿ‘๐Ÿ—จ has left
  541. homebeach has left
  542. Half-Shot has left
  543. Half-Shot has joined
  544. Matthew (away) has joined
  545. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  546. uhoreg has joined
  547. homebeach has joined
  548. Zash Dealing with certbot has been cumulatively more painful by now, and I don't even use it
  549. matkor has left
  550. moparisthebest I only use acme.sh which by default doesn't change your key, so my key is published in a TLSA that never has to change
  551. moparisthebest also still using HPKP...
  552. Zash dehydrated also has the amazing feature of _not_ replacing your keys
  553. Zash Found out recently it can generate keys before using them, for rollover, which I'm in the middle of figuring out how to do.
  554. adiaholic has left
  555. adiaholic has joined
  556. sabry has joined
  557. marc has left
  558. marc has joined
  559. emus has left
  560. harry837374884 has left
  561. harry837374884 has joined
  562. emus has joined
  563. moparisthebest for hpkp I just generated encrypted backup keys years ago and published them, haven't switched to using them yet though
  564. emus has left
  565. millesimus has joined
  566. emus has joined
  567. adiaholic has left
  568. marc has left
  569. marc has joined
  570. BASSGOD has left
  571. moparisthebest Standards-wise I think I'm really leaning towards putting both discovery of connection methods (to replace srv) and key material (to replace Dane+posh) in host-meta, so we aren't adding yet another thing to look up, just parsing more things from the existing one...
  572. sabry has left
  573. adiaholic has joined
  574. moparisthebest In my ideal world with dnssec everywhere we'd just use srv+dane instead, but that doesn't seem likely to happen soon? :'(
  575. papatutuwawa has joined
  576. Matthew (away) has left
  577. uhoreg has left
  578. Rixon ๐Ÿ‘๐Ÿ—จ has left
  579. homebeach has left
  580. Half-Shot has left
  581. Half-Shot has joined
  582. Matthew (away) has joined
  583. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  584. uhoreg has joined
  585. homebeach has joined
  586. qwe has left
  587. xnamed has joined
  588. APach has joined
  589. Menel has joined
  590. Dele Olajide has joined
  591. govanify has left
  592. govanify has joined
  593. govanify has left
  594. govanify has joined
  595. govanify has left
  596. govanify has joined
  597. adiaholic has left
  598. adiaholic has joined
  599. marc has left
  600. marc has joined
  601. harry837374884 has left
  602. matkor has joined
  603. me9 has joined
  604. Dele Olajide has left
  605. rubi has left
  606. rubi has joined
  607. adiaholic has left
  608. fhtest has joined
  609. harry837374884 has joined
  610. jgart has joined
  611. Friendly Resident Cynic has joined
  612. floretta has left
  613. qwe has joined
  614. djorz has joined
  615. me9 has left
  616. karoshi has left
  617. floretta has joined
  618. phryk has joined
  619. karoshi has joined
  620. Steve Kille has left
  621. Steve Kille has joined
  622. djorz has left
  623. djorz has joined
  624. gooya has left
  625. Titi has left
  626. gooya has joined
  627. djorz has left
  628. harry837374884 has left
  629. harry837374884 has joined
  630. julian has left
  631. fhtest has left
  632. djorz has joined
  633. floretta has left
  634. wladmis has left
  635. wladmis has joined
  636. floretta has joined
  637. gooya has left
  638. gooya has joined
  639. BASSGOD has joined
  640. BASSGOD has left
  641. BASSGOD has joined
  642. wladmis has left
  643. wladmis has joined
  644. Steve Kille has left
  645. Steve Kille has joined
  646. qwe has left
  647. guus.der.kinderen has joined
  648. gooya has left
  649. gooya has joined
  650. neshtaxmpp has left
  651. neshtaxmpp has joined
  652. fhtest has joined
  653. neshtaxmpp has left
  654. neshtaxmpp has joined
  655. fhtest has left
  656. fhtest has joined
  657. fhtest has left
  658. fhtest has joined
  659. Titi has joined
  660. gooya has left
  661. gooya has joined
  662. rafasaurus has left
  663. gooya has left
  664. gooya has joined
  665. restive_monk has left
  666. rafasaurus has joined
  667. Dele Olajide has joined
  668. Dele Olajide has left
  669. adiaholic has joined
  670. robertooo has left
  671. adiaholic has left
  672. robertooo has joined
  673. robertooo has left
  674. robertooo has joined
  675. Yagiza has left
  676. qwe has joined
  677. argentum has left
  678. restive_monk has joined
  679. restive_monk has left
  680. jgart has left
  681. jgart has joined
  682. wladmis has left
  683. wladmis has joined
  684. xnamed has left
  685. ti_gj06 has left
  686. ti_gj06 has joined
  687. adiaholic has joined
  688. papatutuwawa has left
  689. wladmis has left
  690. wladmis has joined
  691. karoshi has left
  692. pasdesushi has left
  693. adiaholic has left
  694. Mikaela has left
  695. wladmis has left
  696. wladmis has joined
  697. xnamed has joined
  698. neshtaxmpp has left
  699. neshtaxmpp has joined
  700. ti_gj06 has left
  701. pasdesushi has joined
  702. gooya has left
  703. gooya has joined
  704. karoshi has joined
  705. gooya has left
  706. gooya has joined
  707. Andrzej has left
  708. Andrzej has joined
  709. ponymontana has joined
  710. ponymontana has left
  711. guus.der.kinderen Does anyone have experience with moving a server-implementation from stringprep to precis?
  712. guus.der.kinderen some quick tests on our server show that out of 241277, 68 seem to have issues when trying to compare them to all others.
  713. msavoritias has left
  714. Titi has left
  715. Matthew (away) has left
  716. homebeach has left
  717. Rixon ๐Ÿ‘๐Ÿ—จ has left
  718. uhoreg has left
  719. Half-Shot has left
  720. Half-Shot has joined
  721. Matthew (away) has joined
  722. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  723. uhoreg has joined
  724. homebeach has joined
  725. Titi has joined
  726. Andrzej has left
  727. me9 has joined
  728. karoshi has left
  729. karoshi has joined
  730. adiaholic has joined
  731. Andrzej has joined
  732. floretta has left
  733. andrey.g has joined
  734. Matthew (away) has left
  735. homebeach has left
  736. Rixon ๐Ÿ‘๐Ÿ—จ has left
  737. uhoreg has left
  738. Half-Shot has left
  739. Half-Shot has joined
  740. Matthew (away) has joined
  741. Rixon ๐Ÿ‘๐Ÿ—จ has joined
  742. uhoreg has joined
  743. homebeach has joined
  744. wladmis has left
  745. wladmis has joined
  746. Dele Olajide has joined
  747. andrey.g has left
  748. adiaholic has left
  749. Dele Olajide has left
  750. Dele Olajide has joined
  751. Vaulor has left
  752. Dele Olajide has left
  753. bean has left
  754. fhtest has left
  755. Tobias has left
  756. Seve has left
  757. Seve has joined
  758. Vaulor has joined
  759. floretta has joined
  760. Menel has left
  761. ti_gj06 has joined
  762. Andrzej has left
  763. Andrzej has joined
  764. me9 has left
  765. guus.der.kinderen (I ment to inject 'usernames' in there somewhere)
  766. reimar has left
  767. marc has left
  768. millesimus has left
  769. marc has joined
  770. marc0s has left
  771. marc0s has joined
  772. marc has left
  773. ti_gj06 has left
  774. marc has joined
  775. floretta has left
  776. moparisthebest I thought the consensus was that couldn't be done
  777. Andrzej has left
  778. Seve has left
  779. millesimus has joined
  780. Vidak has left
  781. guus.der.kinderen has left
  782. djorz has left
  783. wladmis has left
  784. floretta has joined
  785. wladmis has joined
  786. karoshi has left
  787. wurstsalat has left
  788. karoshi has joined
  789. djorz has joined
  790. Vidak has joined
  791. chronosx88 has left
  792. Malthe has joined
  793. marc has left
  794. Dele Olajide has joined
  795. wladmis has left
  796. argentum has joined
  797. adiaholic has joined
  798. Malthe has left
  799. jcbrand has left
  800. Alex has left
  801. Titi has left
  802. Dele Olajide has left
  803. phryk has left
  804. djorz has left
  805. djorz has joined
  806. sonny has left
  807. adiaholic has left
  808. alex11 has joined
  809. fhtest has joined
  810. adiaholic has joined
  811. BASSGOD has left
  812. gooya has left
  813. gooya has joined
  814. BASSGOD has joined