XSF Communications Team - 2019-02-26


  1. arnaudj has left

  2. arnaudj has joined

  3. jc has left

  4. alacer has joined

  5. alacer has left

  6. arnaudj has left

  7. alacer has joined

  8. LNJ has joined

  9. alacer has left

  10. arnaudj has joined

  11. LNJ has left

  12. Guus has left

  13. Guus has joined

  14. Guus has left

  15. Guus has joined

  16. ralphm has left

  17. jc has joined

  18. jc

    I still want to create a pubsub module for converse.js that can be used to add comments to a website

  19. jc

    Just don't have the time at all 😒

  20. alacer has joined

  21. alacer has left

  22. arnaudj has left

  23. arnaudj has joined

  24. alacer has joined

  25. LNJ has joined

  26. nyco has left

  27. nyco has joined

  28. Guus has left

  29. Guus has joined

  30. Guus has left

  31. ralphm has joined

  32. arnaudj has left

  33. arnaudj has joined

  34. alacer has left

  35. alacer has joined

  36. ralphm has left

  37. Guus has joined

  38. ralphm has joined

  39. ralphm has left

  40. ralphm has joined

  41. nyco has left

  42. Guus has left

  43. Guus has joined

  44. Guus has left

  45. nyco has joined

  46. arnaudj has left

  47. arnaudj has joined

  48. arnaudj has left

  49. arnaudj has joined

  50. arnaudj has left

  51. arnaudj has joined

  52. Guus has joined

  53. LNJ has left

  54. alacer has left

  55. alacer has joined

  56. pep.

    jc, yeah helping on that pubsub thing is also in my todo somewhere. That would force people to get XMPP accounts, so we also need to work on the onboarding story I guess

  57. jc

    Converse already supports OAuth login, so that could be extended upon to make it easier for people to comment

  58. pep.

    Hmm, would that application be attached to the blogger's XMPP server or sth?

  59. jc

    Could provide a hosted service and if people want to set it up themselves they can as well

  60. pep.

    How does the OAuth thing work? You can limit authorized providers right?

  61. jc

    yes

  62. pep.

    Ok. That would still mean duplication (of accounts) I guess, if some people use the hosted service, and some others use self-hosted services. People using oauth would create accounts on all of these instances

  63. pep.

    *confusion ensues*

  64. jc

    Not if federation is enabled

  65. pep.

    How do I know as a self-hoster what is the identity authority for the guy using oauth?

  66. jc

    Why do you care?

  67. jc

    If you're federating you don't have anything like that for other XMPP servers

  68. pep.

    I don't understand

  69. jc

    You need an XMPP server which supports OAuth login, so ultimately it is still an XMPP account

  70. pep.

    Sure

  71. jc

    And if you federate, then there's not much difference between an OAuth account or a normal account

  72. pep.

    There is

  73. pep.

    Well

  74. pep.

    Ok we're not aligned here

  75. jc

    Ah, you mean the client doesn't allow all authority providers

  76. jc

    well, then that's the way it is

  77. pep.

    No I'm saying,

  78. Guus has left

  79. Guus has joined

  80. pep.

    HosterA, HosterB, Github, userA. userA first creates an account at HosterA using their Github identity,

  81. pep.

    They now have access to AccountsA

  82. pep.

    userA goes to HosterB, do they create an account? What if they don't understand anything at XMPP and they just try to login using OAuth again, creating AccountB on HosterB

  83. pep.

    How does HosterB knows in the first place that AccountA is even a thing

  84. jc

    Depends on how HosterB is set up

  85. jc

    But yes, it could happen

  86. pep.

    That's why I was talking about account duplication, federation or not

  87. pep.

    Or you'd create another big node of users, that hosted service

  88. jc

    Comments aren't federated currently anyway, so either you have a centralized account on Disquss, or on each site that uses its own comments you have a new account

  89. pep.

    If you look at things on the web, that's true

  90. pep.

    If you look at things done in XMPP currently, that's less true

  91. jc

    Yes, I was thinking of having a de facto XMPP server handling OAuth accounts, and people could delegate to that

  92. jc

    And if they really want to self-host OAuth accounts, then they can, then there's account duplication

  93. pep.

    Well the best would be for github to have their own account

  94. pep.

    Well the best would be for github to have their own xmpp server

  95. pep.

    Best, yes and no

  96. jc

    The way I set up OAuth is for each OAuth provider to have it's own VirtualHost on the Prosody server

  97. pep.

    That would be yet another huge hub of users

  98. pep.

    Rigt

  99. jc

    And you could configure converse.js to use those hosts by default

  100. pep.

    Rigth

  101. Guus has left

  102. pep.

    That doesn't really solve my problem, but then I don't know if much can be done for that either

  103. jc

    what is your problem?

  104. SouL

    Having all users at the same place?

  105. alacer has left

  106. pep.

    SouL, that's a problem that arises while trying to solve my problem :/

  107. pep.

    My first issue is,

  108. pep.

    I would like userA to be able to reuse the first account they created on HosterA, while not especially be XMPP-savvy

  109. pep.

    I would like userA to be able to reuse the first account they created on HosterA, while not especially being XMPP-savvy

  110. jc

    That's fine, as long as the client is using the default configuration

  111. jc

    Then it'll route Github logins to the right XMPP sever

  112. pep.

    And I don't want to limit userA to the one big hoster out there

  113. jc

    Well, that's really the issue πŸ™‚ In that case, they shouldn't use OAuth, and 99.99% of the people who use OAuth wouldn't care about it IMO

  114. pep.

    True..

  115. jc

    By using OAuth they're indicating that they don't care

  116. pep.

    But then,

  117. pep.

    Do "we" the community "design" somebody who's going to play the github identity provider? :/

  118. pep.

    Because that's essentially what you're saying no?

  119. jc

    I'm not thinking of doing this for the XSF

  120. pep.

    sure, XSF or not

  121. jc

    This is a personal project, and maybe I can charge for hosting

  122. jc

    And I'd be happy to work with people on it

  123. jc

    Since I'm overloaded as it it

  124. jc

    Since I'm overloaded as it is

  125. pep.

    Yeah that's also something I'd like to work on tbh

  126. SouL

    It is something we need, so..

  127. jc

    I'm looking for sustainable ways to work on Converse.js, and that means generating income

  128. jc

    Not just for me, but for everyone involved of course

  129. pep.

    One other thing, you say "as long as the client is using the default configuration, then it'll router Github logins to the right XMPP server", that means you expect self-hoster to also route github logins to that one big hub?

  130. jc

    pep. Well, once you have time, let me know and we can discuss how to go about it

  131. vaulor has joined

  132. jc

    pep. Unless they configure the client to not do it

  133. jc

    It's the default

  134. jc

    Most people want to allow people to log in with OAuth, because most bloggers want to lower the barrier to entry for spam

  135. jc

    Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for spam

  136. jc

    Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha

  137. jc

    Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha)

  138. jc

    Freudian slip

  139. pep.

    :D

  140. jc

    I was thinking about spam

  141. pep.

    Ok, so really the identity provider I'm trusting is BigHoster, not Github

  142. jc

    You're trusting BigHoster, but I'm not sure it's correct to call it the identity provider

  143. jc

    Github is the identity provider

  144. pep.

    In the case of XMPP it isn't. as self-hoster if I have them create an account on bighoster, I'm trusting bighoster :P

  145. pep.

    I don't even have to know about github

  146. jc

    You're gonna have an order of magnitude more spam from normal XMPP accounts, than from OAuth/BigHoster accounts πŸ™‚

  147. jc

    true

  148. pep.

    Yeah it's not a case of "I'm worried about spam"

  149. jc

    what are you worried about?

  150. pep.

    Just trying to understand and make things clear

  151. pep.

    Trust is always an issue :P

  152. jc

    Any other XMPP server you're federating you have to trust

  153. jc

    BigHoster is just another one

  154. jc

    Any other XMPP server you're federating with you have to trust

  155. pep.

    True

  156. pep.

    btw, unrelated, these 4 messages above were supposed to be LMC?

  157. jc

    Yes

  158. pep.

    I only got the first one corrected

  159. pep.

    20:40:59 jc1> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for spam 20:41:07 jc> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha 20:41:09 jc> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha)

  160. jc

    Bug in poezio πŸ˜›

  161. pep.

    Impossible!

  162. jc

    Oh, Converse.js allows editing earlier messages than the last

  163. jc

    Could be that

  164. Link Mauve

    jc, poezio too.

  165. pep.

    nah, poezio should also

  166. Link Mauve

    jc, my guess is that you corrected the first id three times, while poezio replaces the entire message with the correction as per the XEP, including the id.

  167. jc

    Link Mauve: that sounds right

  168. jc

    So Converse is not spec-compliant?

  169. pep. gets his pointy fingers to point at converse

  170. pep.

    :P

  171. Vaulor has joined

  172. alacer has joined

  173. jc

    I don't actually see that the XEP says this explicitly

  174. jc

    Link Mauve: Can you quote where in the XEP this is said?

  175. Link Mauve

    Hmm, β€œIt is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.”

  176. Link Mauve

    That may mean only payloads, and not attributes of the outer message.

  177. Link Mauve

    But then, why?

  178. pep.

    why what? What this SHOULD?

  179. pep.

    I guess it's mostly for consistency?

  180. jc

    Well well well...

  181. jc

    πŸ˜›

  182. SouL grabs the popcorn

  183. jc

    Should I make a bug report for Poezio? πŸ˜‰

  184. SouL

    Booom

  185. SouL

    Haha

  186. SouL is just joking :D

  187. Link Mauve

    jc, or a fix to the XEP to specify that the stanza replaces the old one, period?

  188. jc

    I'm not sure that this is better...

  189. pep.

    err, do you really want to do that?

  190. Link Mauve

    pep., that’s what we do yes.

  191. jc

    They all replace the original stanza

  192. jc

    I can see arguments for both ways of doing things

  193. Link Mauve

    It avoids having to go back in the history tree up to the root stanza and modify it again.

  194. pep.

    What about all other payloads in the stanza? That means you can remove anything outside of <body/>?

  195. alacer has left

  196. Neustradamus has left

  197. pep.

    (well it's already used for xhtml-im etc., I guess, and also omemo, pgp, and whatnots)

  198. Neustradamus has joined

  199. pep.

    Or wait no, not OMEMO

  200. pep.

    Or at least it shouldn't, privacy [blah blah]

  201. Link Mauve

    pep., yes, all of the payloads, and here I argue that it should also replace the attributes of the stanza.

  202. pep.

    That's not generally something I'm really fond of, mutability :x

  203. pep.

    Also, "hijack commteam@ for your new pet bug 101", available today in your syllabus

  204. jc

    Nothing we've talked about this whole conversation is relevant to this MUC

  205. pep.

    True

  206. pep.

    "How to put XMPP MUCs to good use"

  207. pep.

    So.. open a bug on poezio, and converse, with a "This needs to be resolved by trial by combat on standards@"?

  208. jc

    Well, Converse is spec-compliant as it's currently written

  209. alacer has joined

  210. pep. falls, pointy fingers twisted, defeated

  211. alacer has left

  212. alacer has joined

  213. SouL

    xD

  214. LNJ has joined

  215. pep.

    jc, https://lab.louiz.org/poezio/poezio/issues/3462 :)

  216. jc

    πŸ˜‡

  217. LNJ has left

  218. LNJ has joined

  219. alacer has left

  220. alacer has joined

  221. alacer has left

  222. Neustradamus has left

  223. Neustradamus has joined

  224. alacer has joined

  225. ralphm has left

  226. ralphm has joined

  227. alacer has left

  228. Guus has joined

  229. Guus has left

  230. Guus has joined

  231. Guus has left

  232. alacer has joined

  233. alacer has left

  234. alacer has joined

  235. alacer has left

  236. Guus has joined

  237. ralphm has left

  238. nyco has left

  239. nyco has joined

  240. Guus has left

  241. Guus has joined

  242. alacer has joined

  243. alacer has left

  244. ralphm has joined

  245. Guus has left

  246. Guus has joined

  247. ralphm has left

  248. alacer has joined

  249. vaulor has left

  250. vaulor has joined

  251. alacer has left

  252. arnaudj has left

  253. arnaudj has joined

  254. LNJ has left

  255. jc has left

  256. vanitasvitae has left

  257. vanitasvitae has joined

  258. vanitasvitae has left

  259. vanitasvitae has joined

  260. vanitasvitae has left

  261. vanitasvitae has joined

  262. arnaudj has left

  263. arnaudj has joined

  264. arnaudj has left

  265. arnaudj has joined

  266. arnaudj has left

  267. arnaudj has joined

  268. vaulor has left