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


  188. Zash

    Not mandated by XEP-0313

  189. Tobias


  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


  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


  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


  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


  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


  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


  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