XSF Discussion - 2017-03-01


  1. jonasw

    Ge0rG, :D

  2. jonasw

    (re 21:44:26 Ge0rG> "The "S" in IoT stands for Security." just has become my quote of the year.)

  3. nyco

    huh... is there a board meeting?

  4. Zash

    Never ending board meeting, yes

  5. nyco

    oh right

  6. nyco

    so is the gavel continuously banging? I don't hear it

  7. SamWhited

    (I keep meaning to ask RE the never ending board meeting jokes: is there a subject or something set that mcabber doesn't show? IDGI)

  8. Zash

    /topic

  9. mathieui

    SamWhited, the topic

  10. Zash

    > The room subject is now: Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  11. SamWhited

    Huh, I don't see that; maybe mcabber never updates the subject

  12. SamWhited

    I see

  13. SamWhited

    > XSF discussion room | Logs:…

  14. Zash

    Ha

  15. SamWhited

    oh no, I had this discussion with someone; that's the title of the bookmark (set by Mcabber or Conversations or whatever I added it with) which I guess was the title at the time; mcabber shows whatever the bookmark contains

  16. SamWhited

    These jokes are lost on me :)

  17. Ge0rG

    The subject that is the topic, but not the description?

  18. Zash

    That's ... sorta sensible I guess

  19. Ge0rG

    SamWhited: why should it set the subject as the name?

  20. SamWhited

    Showing the bookmark title seems sensible, not sure about setting the bookmark title to the subject (but I'm also not sure what I created this bookmark with in the first place, so no idea where that came from)

  21. Ge0rG

    Easy XMPP clients will show the disco#info name. I'm sure they will.

  22. SamWhited

    Ge0rG: ¯\_(ツ)_/¯ I think it's probably Conversations that does this, so ask there

  23. Ge0rG

    Unfortunately, the name of this MUC is "xsf".

  24. SamWhited

    maybe we should have a name, a pretty name, a description, a subject, and a bookmark name. *pokerface*

  25. ralphm

    Hi all

  26. nyco

    hi

  27. Ge0rG

    SamWhited: so the first item would be the "ugly name"?

  28. SamWhited

    Ge0rG: yup, the never-changing single-word-no-spaces-no-special-chars name (no idea why, just 'cause). Maybe it's the local part of the JID.

  29. Ge0rG

    SamWhited: see you in the SgmLxqI+A0tOdwPfVXNdd1H4 chat room.

  30. arc

    holy crap.

  31. arc

    Google can't even federate their own chat apps.

  32. ralphm bangs gavel

  33. ralphm

    1. Welcome

  34. Ge0rG

    the board meeting goes into its third week

  35. ralphm

    Who's there, any agenda items?

  36. Martin

    *wave*

  37. dwd takes some minutes.

  38. arc

    Present

  39. ralphm

    I assume nyco, too.

  40. nyco

    yep

  41. ralphm

    Do we have MattJ?

  42. nyco

    https://trello.com/b/Dn6IQOu0/board-meetings

  43. ralphm

    As a note upfront, I've been swamped with work and haven't kept tabs on anything XMPP for the last two weeks.

  44. ralphm

    One item for me is IEEE

  45. ralphm

    anything else?

  46. nyco

    Discourse, Board priorities

  47. ralphm

    OK

  48. ralphm

    2. IEEE

  49. ralphm

    We

  50. arc

    What happened to a decision on software listed on the site?

  51. arc

    That's old business

  52. ralphm

    've received a message from William Miller on IEEE IoT efforts and their desire to incorporate our IoT specs in more of their work.

  53. arc

    But they're not our specs. The XEPs they are referring to are expired and defunct

  54. ralphm

    Asking to move them to Active

  55. ralphm

    I don't want to go into the details in this meeting.

  56. ralphm

    I think we should ask Council to provide guidance on how to move forward, and possibly appoint a liason to the IEEE for this work.

  57. arc

    +1

  58. arc

    third party people implementing defunct XEPs and pushing them as standards to other standards groups is a situation we need council to get on top of

  59. SamWhited

    With my council hat on (though I can't speak for everyone else of course) I think this is a matter for the IoT SIG to decide; if they want to improve the current XEPs, they will be reopened, if not, they can create new ones (possibly while working with the IEEE group)

  60. SamWhited

    But I do agree that if we *don't* want to improve the existing ones (and I think the consensus at the summit was that we don't), then we should definitely be careful to try and stop people from implementing them if there are known issues or we're not going to push them as official standards.

  61. ralphm

    I'm not sure if they really need these specs per se, but rather just XMPP-based ones.

  62. MattJ

    Hey, sorry, another meeting overran

  63. arc

    I'd like someone from board to reach out to Mr Miller re: XSF membership, they should have at least one person from their firm if they're implementing

  64. dwd

    With my Council hat on, the IoT SIG is subject to Council, so if Board asks the Council to Do Something, then I imagine Council will ask the IoT SIG and make a decision based on that input. But a Liaison as a first step seems sensible.

  65. SamWhited nods

  66. ralphm

    And even though there is an IoT SIG, this is exactly why I wanted a Council person to be heading the IoT SIG

  67. arc

    he appears to be in Washington DC given his phone number. I'd be happy to reach out to him, have coffee with him, etc

  68. ralphm

    Sure thing.

  69. ralphm

    SamWhited: can council at least work with Rikard and the IoT SIG to come up with a strategy?

  70. ralphm

    I don't think "we're throwing away the current specs" is a sensible approach to start interacting with IEEE

  71. SamWhited

    ralphm: That sounds sensible; I didn't mean to suggest that we shouldn't be involved. I'll add an agenda item for next week

  72. SamWhited

    https://trello.com/c/5SHoH80M

  73. SamWhited

    Done; comments can go there if you want us to discuss anything in particular next week.

  74. ralphm

    Who wants to formulate a response to William to kick off interaction with the IEEE?

  75. ralphm

    I'd like that to not wait until next week

  76. dwd

    Is that not Arc's coffee meeting?

  77. ralphm

    Maybe yes

  78. arc

    im not going to meet with him about IEEE as much as to understand what his firm is doing and explain what XSF is, encourage membership, etc

  79. arc

    leaving council issues aside, the part of the email that stuck out is he's speak from outside the XSF. and we really want implementors in the XSF.

  80. dwd

    I'd have thought that's a reasonable first response.

  81. ralphm

    arc: sure, we can to the actual IEEE liasoning or whatever later.

  82. arc

    I think council does need to come up with a strategy for the iot stuff besides this

  83. dwd

    arc, Agreed.

  84. ralphm

    Yes, so that's part of what SamWhited's agenda item

  85. ralphm

    Any other comments on this?

  86. MattJ

    None here, sounds like a plan

  87. ralphm

    3. Discourse

  88. Martin

    Yep, sounds good to me

  89. ralphm

    nyco?

  90. nyco

    yes, the thread on the mailing list

  91. nyco

    also: Je pense

  92. SamWhited

    RE Discourse: If this is seriously being considered, I would like to have a(nother?) public comment period so that I can complain about what a terrible experience it is a lot. I won't waste time in the council meeting with it though.

  93. nyco

    oops

  94. nyco

    https://trello.com/c/qcPd55vA/260-use-discourse-on-discuss-xmpp-org

  95. SamWhited

    s/council/board/

  96. dwd

    nyco, Donc, je suis?

  97. nyco

    more or less ;-)

  98. ralphm

    I haven't read the discussion in great detail, but don't feel we have problem that needs resolving here

  99. ralphm

    on a technical level

  100. nyco

    we indeed have issues, that are worth admitting

  101. nyco

    Discourse is a great solution

  102. arc

    I'm not so hot on Discourse too, and agree with the sentiment that we should aim for an XMPP based solution

  103. MattJ

    I haven't used it, so can't really comment

  104. arc

    adding a new discussion media is a long term burden to the XSF that shouldn't be done lightly

  105. nyco

    we discussed quite extensively at the Summit around modernism we lack this, like very badly also, we should lower the barrier of entry

  106. ralphm

    I'm happy for people to play with this, but I'd hate to use this as a main thing for any of our current mailing lists before gaining significant experience.

  107. nyco

    ralphm, mailing list is still there

  108. MattJ

    Maybe we could trial it for some discussion venues, but not others?

  109. nyco

    MattJ, IoT WG

  110. ralphm

    nyco: but not the mailman archives, right?

  111. nyco

    MattJ, also maybe if we wake the CommTeam back from the dead?

  112. dwd

    nyco, No, thanks. I'd rather it was used for jdev, or something else that's not a SIG.

  113. nyco

    ralphm, better archives, with real search that brings actual results, and tagging

  114. SamWhited

    Worth answering (but not necessarily right now): If we trial it for a WG, can we be sure that we can get to the archives later or move back to a mailing list if we decide not to use it long term?

  115. ralphm

    I a trial can be done without any changes in the current setup, as an add-on, I'm ok

  116. SamWhited

    (or anywhere really, but especially if it's an official function of the XSF like a WG)

  117. ralphm

    if

  118. Flow likes to point out that the IoT SIG would want to use discourse

  119. ralphm

    nyco: I'm sure everything is nicer, better, awesomer. I'd like to not have an disruption to the current setup.

  120. ralphm

    any

  121. nyco

    ralphm, agree

  122. ralphm

    Flow: I know, but I also don't want IoT to not be on an island. Especially not IoT.

  123. nyco

    mailman 2 is an island

  124. nyco

    we're all on it... :'(

  125. dwd

    How about setting up an entirely new discussion venue?

  126. ralphm

    dwd: hm?

  127. MattJ

    That's kinda what I meant

  128. nyco

    dwd, yeah on Slack!

  129. dwd

    Create, say, a UX "list", but make it Discourse (or something) instead.

  130. ralphm

    Oh. In that case, something like SCAM would be appropriate

  131. MattJ

    Some measurement of success would be to ensure not just that the new system was used, but also that existing XSF members participated in it

  132. ralphm

    Right

  133. arc

    to quote the Zen of Python, "Now is better than never, Although never is often better than *right* now."

  134. nyco

    or not

  135. MattJ

    We don't want to throw out our existing community in an attempt to appear shiny to other groups of people

  136. nyco

    ity uccess, right?

  137. arc

    I want to reraise the issue that Discourse is not in any way XMPP based.

  138. MattJ

    I'd wager most of our existing community is just fine with the current setup (except searchable archives would be nice)

  139. arc

    this was a concern raised on the thread.

  140. Flow

    Look at Discourse as you would look at an upgrade from Mailman2 to Mailman3

  141. ralphm

    So the question becomes, who is doing it?

  142. MattJ

    arc, for that matter, mailman is in no way XMPP based :)

  143. Flow

    Nobody is throwing out the existing community by using Discourse

  144. nyco

    arc, so it mailman

  145. nyco

    is

  146. arc

    mailman is simply email. It doesn't use fancy realtime features more suitable to XMPP

  147. MattJ

    Flow, that sounds great - though I've heard conflicting opinions on whether that's true (I can't say myself as I haven't used it)

  148. ralphm

    We're in overtime.

  149. nyco

    we will attract non-members, which is good(tm)

  150. ralphm

    So, again, who's taking this on, and do what?

  151. Flow

    ralphm: I already volunteered

  152. SamWhited

    I've been using it for the past few weeks since this came up; I resubscribed to the rust-users list (which I unsubscribed from before a few weeks after they moved to Discourse) to see if things had changed. I turned on mailing list mode, and used it from my client. It was not a plesant experience.

  153. nyco

    let's just start to install it for IoT SIG

  154. MattJ

    SamWhited, concrete issues would be helpful to know (but not necessarily right here right now)

  155. arc

    I'm -1 on implementing this. I don't think a strong enough argument has been made for its need, and it could add a signifigant future burden to migration in the future

  156. nyco

    the current experience is less than pleasant

  157. nyco

    stuck in the past

  158. nyco

    we need that wave of modernism

  159. nyco

    well contemporarism

  160. SamWhited

    I think I outlined them on the list last time, but if this discussion starts up I'll go through and write out the individual pain points again.

  161. ralphm

    I'm -1 on implementing this for an existing group, and specifically for IoT

  162. nyco

    they want it

  163. ralphm

    They also wanted Skype for Business

  164. MattJ

    Let's (someone?) set up a new venue for starters, that's an actual first step

  165. nyco

    so you're saying what they want is irrelevant?

  166. arc

    nyco: I don't disagree with you that this would be good, the arguments against Discourse are on the merits of Discourse itself, not against innovative solutions

  167. ralphm

    nyco: no, I'm saying that we as an organisation are responsible for it working properly

  168. MattJ

    Then after it's up, we can discuss moving venues to it at a later date

  169. SamWhited

    Not irrelevant, but also not the top concern; they may want it, but the rest of the XSF has to read this stuff too, and having archives will be important later. There are just more considerations than "they want it and it's shiny"

  170. ralphm

    and I think IoT has other, bigger issues

  171. arc

    nyco: I am not joining the IoT SIG exactly because of their choices of non-XMPP mediums for discussion.

  172. Flow

    arc: We use Jitsi Meet since months

  173. MattJ

    I have no idea what work is currently being done in the IoT SIG, nor how to find out

  174. MattJ

    I didn't know it was still active

  175. arc

    exactly, MattJ

  176. nyco

    Discourse will make that visible... ;-)

  177. MattJ

    Mmmmhm

  178. Flow

    The visibility of Mailman2 mailing lists

  179. Zash

    Can you all pretend that I asked "Why?" to every statement in here?

  180. Flow

    I'm sure you can easily follow what happened in iot@ by reading the mailman2 archive

  181. Flow

    , not.

  182. SamWhited

    Why would Discourse make that any easier to follow?

  183. ralphm

    nyco: it wouldn't make it more visible. The last message before today was January 8

  184. nyco

    ralphm, yes, it would, that's one of the points

  185. ralphm

    https://mail.jabber.org/pipermail/iot/

  186. Flow

    SamWhited: No subpages per months, as starter.

  187. ralphm

    I can follow my e-mail client archives just fine, and I agree with MattJ

  188. MattJ

    Didn't the IETF have a nicer browser for mailman archives, if this is the issue?

  189. SamWhited

    Oh, I see, you're assuming the web interface. Yah, that's pretty bad, however, Discourse's non-web interface is pretty bad, so we're just trading one bad interface for another.

  190. Flow

    MattJ: That's one of the issues

  191. MattJ

    i.e. I'm sure existing work has been done in this area

  192. nyco

    ralphm, so can you with Discourse

  193. ralphm

    nyco: my point is that I don't believe non-movement in IoT is going to be solved by new technology for discussion

  194. nyco

    ralphm, true, but non-movement on our discussion means are killing

  195. Flow

    ralphm: As Guus what he thought about moving Openfire to github years ago. And read what he now writes in the ignite realtime blog

  196. Ge0rG

    Can't we just ask politely to add the list of affected xeps into the subject when posting to our lists?

  197. Zash

    There are prettier web frontends to mailing lists around, like Nabble, http://lua.2524044.n2.nabble.com/

  198. Zash

    So it's doable

  199. SamWhited

    That's different; GitHub is a central community with network effect. A Discourse instance isn't.

  200. arc

    I think the correct way forward on this is to have a discussion session for future-comms where multiple solutions can be discussed. Not simply a "I think we should move to X solution".

  201. nyco

    Zash, still ugly and old style, frightening

  202. ralphm

    arc: form?

  203. nyco

    SamWhited, to achieve network effect thanks to its value, then do lower the barrier of entry

  204. SamWhited

    nyco: However, for many it reduces value

  205. arc

    mailing list or a MUC chat

  206. Flow

    No, correct way to move forward is to do something. But within the XSF you will always find someone who is opposing that is why nothing happens ever.

  207. nyco

    SamWhited, I'm saying network value, Metcalfe's Law

  208. nyco

    Flow, agree, non-action hurts so badly

  209. Flow

    It was similar with the new xmpp.org homepage

  210. nyco

    don't give me the problem of resources

  211. Flow

    Simon also got yelled at for trying to move forward

  212. nyco

    the non-members, the external communities than we need so badly, will welcome that move

  213. ralphm

    Flow: ok, if you can set up Discourse in such a way that we *also* keep having archives in Mailman as we have now, you have my blessing.

  214. ralphm

    Is that possible?

  215. arc

    I'm ok with that, too.

  216. nyco

    why not disrupt?

  217. nyco

    are you doing nothing, to keep the comfort of a few?

  218. Flow

    ralphm: My idea was roughly to start with a test setup, and then switch one ML after another ot discourse and then eventually make mailman2 read-only.

  219. dwd

    nyco, You know that disruption isn't a means to an end?

  220. nyco

    dwd, ;-)

  221. ralphm

    Flow: ok, but can you run in hybrid mode?

  222. arc

    Flow: enough concerns have been raised to that, its not going to happen

  223. Flow

    We can always try to find someone to migrate the old posts to discourse if we want

  224. Flow

    arc: Concerns like?

  225. nyco

    arc, enough concerns have been raised to stay that way

  226. arc

    this isn't one person objecting. several people have concerns over the proposal

  227. Flow

    ralphm: hybrid mode?

  228. nyco

    arc, several people are all for it

  229. nyco

    if we want actual numbers, we can call for a survey

  230. arc

    something as fundamental as our communication medium affects everyone. for that, there should be rough consensus to change.

  231. SamWhited

    This isn't about numbers or a vote, it's about the people who are for it assuming that the burden of proof to show that this is a good idea is on everyone else and not addressing the valid concerns brought up by others on the list.

  232. Flow

    yeah, a members vote would be great thing to get a feeling what the XSF members think

  233. SamWhited

    (although I'm not against gathering numbers or data, of course, why not? Sounds nice.)

  234. nyco

    arc, the state of our current infra is affecting everyone, including the ones who don't join, because...

  235. Flow

    SamWhited: I think I've addressed most, if not all, concerns raised on the ML thread

  236. dwd

    Flow, I think running up a discourse instance with a real - but not critical - workload would be a sensible step.

  237. dwd

    Flow, We could also then try other options (Movim, maybe?).

  238. ralphm

    Flow: what I said before: if you can run it such that messages go to both Discourse and Mailman's archive, then please go ahead

  239. ralphm

    Same with other platforms

  240. nyco

    dwd, why Movim?

  241. dwd

    nyco, Why not?

  242. ralphm

    I want to stop this discussion as part of this meeting now.

  243. nyco

    dwd, because mailing list?

  244. nyco

    ok

  245. arc

    Flow: If I'm not mistaken, what you want is a more modern communications medium. Your chosen solution to that is Discourse. But other solutions could meet your needs. That is why we should discuss this in a new-comms meeting

  246. nyco

    arc, I have not seen any equivalent, please enlighten us

  247. ralphm

    please stop

  248. arc

    ralphm is right, we're way over time.

  249. Flow

    ralphm: Well I suppose you could do that with the help of your MTA. But I'm not sure if it's a good idea. What would be the advantage?

  250. nyco

    so, we end the meeting? or address the last agenda item?

  251. ralphm

    Flow: I want to either have a setup that doesn't involve current workgroups so we can test, evaluate, *or* something that doesn't affect the current infra

  252. ralphm

    (so that Discourse would just be an alternative interface)

  253. nyco

    I propose we put an end to that meeting

  254. MattJ

    Seconded

  255. ralphm

    nyco: I'm still at the office with a 2 hour commute ahead. I'm going to end this meeting

  256. nyco

    the neverending meeting may have a one-week pause

  257. ralphm

    I'm happy for people to keep discussing this afterwards

  258. nyco

    ok then thanks all! it was a great discussion!

  259. ralphm

    4. Date of next

  260. ralphm

    +1W

  261. nyco

    +1

  262. ralphm

    5. Close

  263. ralphm bangs gavel

  264. ralphm

    Thanks all!

  265. MattJ

    Thanks

  266. nyco

    thx, see yah

  267. arc

    Thanks ralph

  268. Martin

    Thanks ralphm,

  269. SamWhited

    Flow: Yah, sorry, went back and looked, I never did send my concerns about it, so obviously you didn't reply to them :) will do that next time this comes up on the mailing list or whenever arc's comms meeting happens.

  270. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  271. Flow

    It's interesting how our experience divergates. Discourse has major traction within the open-source forum software. I find it very enjoyable on mobile and on my workstation, and I really like that I can use it just like mailman

  272. ralphm

    Flow: please don't feel discouraged. I am really curious about new things, but worried about inertia and continuity.

  273. Zash

    MattJ: https://mailarchive.ietf.org/arch/

  274. MattJ

    Zash, I know. Source doesn't appear to be available?

  275. MattJ

    Can't find it

  276. SamWhited

    I'm pretty sure the disagreement is going to be starkly divided down the line of how it's used: If you use the web/mobile apps, it's very nice. If you use it as a mailing list, it's terrible.

  277. Flow

    Well I already decreased my investment in XSF stuff, because it is nearly impossible to change something. Discourse on the other hand is something that I really think the XSF needs most right now. So it's the only thing I currently pursue

  278. Flow

    SamWhited: Did they run a version which included https://github.com/discourse/discourse/commit/74b6fe8739d86dc2284707e8507ac732420a1b8c ?

  279. SamWhited

    I still don't understand what benefit it gives us that a search box and a slightly nicer interface wouldn't

  280. Zash

    MattJ: https://trac.tools.ietf.org/tools/ietfdb/browser/ maaybe?

  281. Flow

    It's not only the search box

  282. Flow

    Just hat you can tag threads with the xep numbers is a huge win IMHO

  283. SamWhited

    Flow: That was one of the changes between last time and this time when I tried it, they did, and it was *much* better. But still a pretty terrible experience.

  284. Flow

    Looking forward to your elaboration what made it so terrible on members@ thread

  285. SamWhited

    (or at least, I assume that was one of the changes; that would explain a lot of the improvements around replying)

  286. MattJ

    Zash, well done

  287. Flow

    Our Mailing List, especially standards@, is a huge pile of valuable information, yet it's not really accessible

  288. SamWhited

    It sends a bunch of garbage HTML, doesn't use conventions in the plain text version (and leaks some form of [bbcode] or something into the plain text), it sends different "topics" from different email addresses so it's hard to write filters (though admittedly, this sounds like it could be how the rust-users and rust-internal instances were configured), off the top of my head. There were others; replies were broken somehow still, but I don't recall now, I'd have to go look.

  289. MattJ

    Flow, Discourse won't fix that unless it can import the archives (can it?)

  290. Flow

    Sure you can. You just probably need to write the code doing so

  291. Flow

    But I think 1. that there are many mailman2 instances upgrading to discourse, so it's only a matter of time until someone does write that code

  292. SamWhited

    What's wrong with this IETF thing? It looks nice and would fix the accessibility problem (assuming we can get the source from them, which I'm sure we could)

  293. arc

    Flow: again, I think decoupling the specific solution you've chosen to champion from the needs to be addresed is a good first step

  294. Flow

    and 2. we can always do the import later

  295. SamWhited

    What arc said

  296. Flow

    yeah, i'm already sold on discourse for various reasons

  297. Flow

    so I don't need to decouple that

  298. SamWhited

    You do if you want to convince anyone else

  299. Flow

    true, but not everyone

  300. Flow

    IMHO Discourse is without alternatives and the best horse to bet on

  301. arc

    that's not a great position to bring to a discussion like this.

  302. Flow

    why not? I try to back my claims with arguments. And I'm happy if you convince me of an different alternative

  303. Zash

    Flow: Take this: https://tools.ietf.org/html/rfc6778 s/IETF/XSF/ and call it a day ;)

  304. arc

    I haven't made a decision yet. What you're feeling as push-back is against the "right now" aspect to your drive. XSF has used MUC and email forever. The board, council, and most WGs use these.

  305. arc

    The first part of the push-back is the expediency, people have said that the case hasn't been made to why these things have to change right now.

  306. MattJ

    Well to be fair, if not "right now" then it'll be never, based on experience :)

  307. arc

    "Now is better than never, although never is often better than *right* now"

  308. arc

    that comes from the python-dev list. very (very) often people comes through saying that X or Y or Z is mission critical, that Python is driving away potential new users because it doesn't have a feature, or a change to the C-API is absolutely necessary or they couldn't use Python, etc

  309. arc

    in almost every case decisions made "right now" are regretted.

  310. SamWhited

    Maybe someone (don't really care who, but it probably shouldn't be someone who's completely against Discourse like me, or completely for it like Flow) should evaluate several options and report back instead of us just making it an argument about "discourse or nothing". Other options have been thrown out, but the gist of the argument has mostly been about moving to discourse, not about improving in general.

  311. arc

    MattJ is right, we need to act on it or it'll be forgotten. So Flow and nyco have ruffled feathers, people are activated, lets sit down like engineers and sort out what we want to do

  312. arc

    I have questions as to MIX - in 2 years when we're all using MIX instead of MUC, will it be possible to merge our chat conversations with mailing list conversations in a meaningful way

  313. nyco

    The timeline may be of a lesser importance here

  314. Zash

    Merging slow, long form communications with quick, short form comms is probably not very easy in non-technical ways.

  315. arc

    im thinking more in terms of archives

  316. Zash

    Ha

  317. Zash

    https://trac.tools.ietf.org/tools/ietfdb/wiki/ProjectSetup#CheckingouttheSourceCode

  318. arc

    Zash: what is this?

  319. MattJ

    Modern

  320. Zash

    arc: I don't know. Unless I've gotten lost, it may be the source code to https://mailarchive.ietf.org/arch/

  321. MattJ

    I think this is just the archive stuff: https://trac.tools.ietf.org/tools/ietfdb/browser/mailarch/trunk

  322. SamWhited

    (if we can find the source, we should try it; this is very nice)

  323. arc

    its an archive front-end to mailman?

  324. SamWhited

    Although if you want to post from a web interface, which might be one of the discours peoples desires, it's hard to tell, it won't help

  325. MattJ

    RabbitMQ dependency... doh

  326. arc

    lol

  327. arc

    what is it using rabbitmq for?

  328. MattJ

    They seem to have some independent processes, maybe for syncing with the mailman archive and indexing

  329. arc

    holy crap. its march 1st. I can code again.

  330. MattJ

    Go slow, maybe stick with just Lua for a while :)

  331. arc

    i have a month of ideas for libexi

  332. arc

    you should see the pages of rubics cube algorithms ive written out

  333. arc

    but the month off was good i think. my vocabulary has returned, i should see the doctor again before i start again though

  334. arc

    get a new baseline to see what the month break resulted in

  335. arc

    i'll just read today.

  336. Zash

    dwd, ny?

  337. dwd

    Oh! That's where that went.

  338. dwd

    So I *entirely* lost that while typing, and had no idea it was actually sent.

  339. Zash

    heh

  340. SamWhited

    Zash: I think this is the mailing list stuff the IETF uses that we were looking for earlier: https://code.google.com/archive/p/ml-archive/

  341. SamWhited

    It has some similarly named resources anyways…

  342. Zash

    > 404. That's an error. > The project ml-archive was not found.

  343. Zash

    SamWhited: I found some svn repo with some Python stuff in it.

  344. SamWhited

    I just clicked through to the sources and now it says there isn't any… something weird is happening.

  345. Zash

    Yay Google

  346. Zash

    /lastlog recent links I've pasted here

  347. SamWhited

    Zash: Oh, I thought the one you posted Mat or somebody said was just a database or something

  348. SamWhited

    but yah, looks like it… nevermind, already found.

  349. Zash

    SamWhited: I don't know for sure what I found, I've stayed too far from python web dev to know how to get whatever it was running.

  350. SamWhited

    That's a smart plan.

  351. Zash

    Worked with a homebrewed Python + MongoDB web framework at my last job.

  352. Zash

    Email, sigh.

  353. Zash

    The thing in XMPP where the same connection is used for incoming and outgoing traffic is pretty nice.

  354. Ge0rG

    Zash: like in s2s?

  355. Zash

    Ge0rG: {xep 288}

  356. Bunneh

    Ge0rG: XEP-0288: Bidirectional Server-to-Server Connections (Standards Track, Draft, 2016-10-17) See: https://xmpp.org/extensions/xep-0288.html

  357. Zash

    Ge0rG: I mean the feature where I don't have to type my password 3 times to send an email.

  358. Zash

    Or have 3 different passwords.

  359. Ge0rG

    I haven't entered my password for email in the last three years. It's stored in a plaintext config file

  360. Zash

    I haven't figured out how to save my password in mutt yet.

  361. Zash

    So I get the pleasure of typing a password for IMAP, a password for GPG and a password for submission.