XSF Discussion - 2020-09-03

  1. Guus

    I thin we've once discussed whether personal MAM archives should or should not include messages exchanged with a MUC by the archive owner. Was there consensus?

  2. Zash

    It's awkward as long as MUC is the way it is, as you see 0 or more messages depending on how many clients are online and joined

  3. Ge0rG

    I think the consensus is to exclude type=groupchat from personal MAM, but then you end up with MUC-PM duplicates

  4. larma


  5. larma

    FOSDEM will be an online event next year, so what is going to happen to summit?

  6. vanitasvitae

    Online summit?

  7. vanitasvitae

    The XSF could host a jutsi meet

  8. larma

    Not sure how good this would work online. Those that joined remotely usually were mostly excluded from discussions

  9. vanitasvitae

    So next year everyone will be eual 😛

  10. vanitasvitae

    So next year everyone will be equal 😛

  11. vanitasvitae

    Online Meeting is always < RL Meeting, but what else can we do?

  12. pep.

    Maybe with everybody online this time people generally present would pay more attention to the others :)

  13. pep.

    Somewhat similar to a company where a small party works remotely, compared to a majority working remotely

  14. pep.

    Somewhat similar to a company where a small part works remotely, compared to a majority working remotely

  15. larma

    vanitasvitae, maybe by february we have vaccination? Than RL meetings really wouldn't be a big deal

  16. larma

    Or just quarantine for 14 days before summit 😀

  17. vanitasvitae

    fingers crossed

  18. vanitasvitae

    and i can imagine that more folks will choose to stay at home despite a vaccine

  19. larma

    Yeah, without FOSDEM it's less worth traveling to Brussels

  20. larma

    maybe instead of decentralized online summit, we do federated online summit? People gather in smaller groups and those join a conference call

  21. Kev

    If we could do an online sprint there might be merit too.

  22. Kev

    An online XEP-sprint, that is.

  23. vanitasvitae

    > maybe instead of decentralized online summit, we do federated online summit? People gather in smaller groups and those join a conference call That sounds like a good idea!

  24. vanitasvitae

    We could hack in smaller groups on dofferent topics and every now and then come together online to discuss what has been done and what will need to be done

  25. vanitasvitae

    Hehe I really like the term "federated summit"

  26. jonas’

    that’s a terrible idea

  27. jonas’

    group/room microphones are terrible

  28. vanitasvitae

    Then maybe organize some mics that are handed around?

  29. Zash

    Physical rooms?

  30. vanitasvitae

    We could go for either.

  31. jonas’

    vanitasvitae, also annoying

  32. jonas’

    and still requires meeting people IRL

  33. vanitasvitae

    I wouldnt say it *requires* people to meet irl

  34. Guus

    Handing mics around using the postal services seem inefficient though.

  35. Guus

    Handing mics around using the postal services seems inefficient though.

  36. ralphm

    0. Welcome

  37. ralphm


  38. ralphm bangs gavel, too

  39. MattJ


  40. pep.


  41. Guus


  42. MattJ

    Seve sent apologies

  43. ralphm


  44. ralphm

    1. Minute taker

  45. Guus

    Ill do it

  46. ralphm

    2. MIssion statement

  47. ralphm

    This is in items for discussion. Was this already discussed?

  48. Guus


  49. Guus

    not in a board meeting, at least.

  50. ralphm

    Ok. I did some digging on this not too long ago. If the problem is "did board officially adopt this mission statement?", then I believe the answer to be yes.

  51. ralphm

    I don't have the references handy right now, but that's what I gathered from the various mail threads around the time it was written.

  52. ralphm

    I also do not think the mission conflicts with a neutrality stance.

  53. pep.

    I disagree with this statement and I guess you're all already aware

  54. ralphm

    Oh, we discussed this on July 16, too.

  55. pep.

    Yeah we did once

  56. ralphm


  57. ralphm

    From a quick reread, I think we agreed to disagree, where the majority seems to not think this is a problem.

  58. ralphm

    Anything we need to discuss further?

  59. pep.

    Also related: https://www.mnot.net/blog/2020/08/28/for_the_users, that I linked last week

  60. Guus

    linked where?

  61. pep.


  62. Guus

    I missed it.

  63. Guus

    I'm still at the same place where I was a couple of months ago: to me, this all feels like a semantics discussion where I've yet to see tangible results.

  64. pep.

    TL;DR: “So at its heart, The Internet is for End Users is a call for IETF participants to stop pretending that they can ignore the non-technical consequences of their decisions”

  65. pep.

    Guus, I'm not entirely sure what you call tangible

  66. pep.

    I think that's actually the main goal of board, to discuss of what you all call meta-stuff

  67. ralphm

    I haven't read that fully yet, but I'm not sure how the XSF is pretending that they can ignore non-technical consequences of their decisions, if that's the implication.

  68. pep.


  69. pep.


  70. ralphm


  71. pep.

    Even the mission statement is not clear on who are priorities are. It states « freedom, openness », but these words mean nothing without any context and they can be used for anything

  72. MattJ

    So we need to include in the mission statement definitions of all the terms?

  73. pep.

    Maybe be slightly more specific? For exemple even just mentioning (end-)users

  74. MattJ

    As far as I'm concerned our protocols are open (they are developed and published publicly) and free (anyone can use them)

  75. pep.

    (And of course applying it afterwards, not just for show)

  76. pep.

    MattJ, good. Now who are these protocols designed for, what purpose. Does the XSF accept anything that comes by? If so why? Or why not?

  77. ralphm

    The mission statement doesn't live a vacuum. It lives on our website, so it other documents go into details, like https://xmpp.org/about/technology-overview.html. Additionally there are well-established meanings behind these words. I am not sure we need ironclad definitions.

  78. MattJ

    I don't think that level of detail belongs in a mission statement. Maybe in some other document...

  79. pep.

    Whatever the answer to these questions these are choices that the XSF (board / members) has to make, and choice means taking sides

  80. pep.

    So no we are not neutral, even if we haven't answered these questions they are answered implicitely

  81. pep.

    Anyway I encourage you to read that blog article, and the RFC that goes with it

  82. ralphm

    Yes, it might be that we decide to non accept a submission. Usually this is on technical grounds. Sometimes on license issues. I don't think the XSF is 100% neutral. We encourage, and require at a stage, open source implementations. But we do not, as an organisation, favour particular contributors or specific implementations.

  83. pep.

    Would we accept a spec that encourages tracking users for example

  84. pep.

    Also just the use of the word "open-source" and not "free software", etc. etc.

  85. Syndace

    Sorry to interrupt, where would I find said mission statement? Is it the first paragraph of https://xmpp.org/about/xmpp-standards-foundation.html ?

  86. pep.


  87. Syndace


  88. pep.

    It's not linked from anywhere :/

  89. ralphm

    We can fill hours of discussions on the difference between Open Source and Free Software.

  90. Ge0rG

    I'd also like to contribute a small AOB topic to the meeting: the IETF's use of Jabber.

  91. Guus

    To me, this feels like an never-ending rabbit hole of trying to preemptively define everything - I wonder what the benefit will be of us putting in the time and effort to do so.

  92. ralphm


  93. pep.

    ralphm, the actual difference is not the point. The mere fact that there are differences is a clue that choices have been made and this is not neutral

  94. MattJ

    The "neutral" thing is being thrown about a lot, did we actually formalize any statement on what this means?

  95. ralphm

    But what is the *problem* with that then? We are not 100% neutral, and I also don't think we claim to be.

  96. pep.

    MattJ, I haven't seen any :/

  97. ralphm

    So where does this perceived incongruence come from?

  98. MattJ

    The primary neutrality that I am concerned with is one of implementation neutrality, along the lines of the question that was included in the members survey a few years ago

  99. pep.

    ralphm, don't we? Maybe not publicly but everybody present here at least has heard of the so-called neutrality I'd hope

  100. pep.

    There has even been a poll a few years ago

  101. MattJ

    i.e. the idea that the XSF should not favour/promote certain XMPP projects above others

  102. MattJ

    It's nothing to do with favouring one or another stance on protocols

  103. pep.

    Guus, is it not important to define who we're doing what we're doing for?

  104. ralphm

    To me, the XSFs so-called neutrality is focussed on the ability for everyone to implement protocols we standardize in our process, and not actively promote certain implementations over others.

  105. pep.


  106. pep.

    I mean, not developers, obviously they're gonna be the ones using the technology, but who is that technology for

  107. ralphm

    And we did have a loooong discussion on the Signal protocol used in our XEPs, *because* of the neutrality stance on this point.

  108. pep.

    I disagree on why we had that discussion, but that's another story

  109. ralphm

    Well, it was had, and we had an opinion.

  110. ralphm

    And to be clear Dave did raise that discussion to its fullest because of that specific reason.

  111. ralphm

    (hi dwd)

  112. pep.

    I still disagree, and that's a discussion we can have later if you want. That does relate to that so-called neutrality certainly

  113. pep.

    And who we're making/accepting protocols for

  114. pep.

    I note that nobody answered "Would we accept a spec that encourages tracking users for example" :)

  115. Guus

    Did that issue come up in the last ~20 years?

  116. MattJ

    Nobody has proposed such a spec, so discussing it is helpful how?

  117. Guus

    and if it did, don't you think we can handle those on a case-by-case basis?

  118. MattJ

    There are many thought experiments we could run along similar lines, but I don't see the benefit

  119. MattJ

    Even if we made a decision now (before any such spec has been submitted), what's to say our stance couldn't change?

  120. ralphm

    we would, as the IETF does. The statement refenced by pep. was accepted by the IAB, not the IETF itself.

  121. MattJ

    Would we preemptively accept such a spec by saying "yes" to your question now?

  122. pep.

    Guus, I don't, actually. That's a pretty obvious example of what people might be uneasy about, but there are plenty of other exapmles, more subtle

  123. ralphm

    (case by case, I mean)

  124. pep.

    ralphm, surely it's "only" the IAB (and yeah that's another excuse I hear often), but it still has quite a lot of weight

  125. ralphm

    It all depends on what "tracking users" means in the context of that hypothetical specification.

  126. ralphm

    pep., and that weight is felt in our community too. I don't see us actively opposing that.

  127. pep.

    I see us talking about things that are opposite to this. What does « neutrality » even mean in the context of this hypothetical spec?

  128. pep.

    "yeah well we're neutral we'll accept your spec, sure"

  129. pep.

    A more concrete example maybe. I read that two weeks ago board voted to support/sponsor an event on message encryption or something,

  130. pep.

    Great, I would probably have agreed as well (even though I now think it might have been a SCAM matter? anyway). But why?

  131. pep.

    Why do we care about message encryption

  132. pep.

    I have my answers obviously, and they are political

  133. pep.

    Not neutral.

  134. pep.

    (I don't even know what neutral would mean here tbh)

  135. ralphm

    I saw a no-objection mention in minutes. It covers messaging, a space the XSF seems to live in. Why is that a neutrality issue?

  136. pep.

    Ok so, whatever comes in we'll just accept? Is that what that means to you?

  137. pep.

    What if tomorrow encrypting things becomes illegal in most of the world? (note that it already is in some countries)

  138. pep.

    Is the XSF explicitely going to support evil people wanting to encrypt messages

  139. ralphm

    In the context of the earlier discussion on Signal, MLS has come up several times. It makes sense to me to be involved with topics like that, so that if people want to do encryption of message, there's a common way that also works for XMPP.

  140. Zash

    Secure Messaging Summit, that's happening today and tomorrow?

  141. ralphm

    No only good-doers.

  142. pep.

    ralphm, but they'd be against the law!!

  143. ralphm

    There's no 'the law'.

  144. pep.

    Isn't there. Not that I care much about it either and I'd explicitely support encryption even if it was illegal in most countries.

  145. pep.

    (Because it is illegal in some countries already, as mentioned above.)

  146. Guus

    Can we come to some kind of conclusion please?

  147. ralphm

    I don't think this discussion is leading in a particular direction. pep.: if you really want to change something here, you need to make it more concrete.

  148. pep.

    I say we drop the neutral stance, because it doesn't actually mean anything (or at least I'd expect some document defining what this means to us), and we aren't neutral anyway (according to my definition).

  149. vanitasvitae

    Or rather than dropping it, define explicitly in what ways the XSF is neutral and in which not?

  150. pep.

    Might as well put that in the mission statement or similar document and say how we'll do things and how we won't do things. Instead of clinging to that notion of neutrality

  151. pep.

    And there maybe we'll realize it's not that easy

  152. vanitasvitae

    As in "the xsf is neutral in regards to implementations, but will protect end-users™"

  153. pep.

    Fortunately(?) we don't have the same trafic as the IETF

  154. Guus

    I do not like the optics of removing a 'neutral' stance - even without defining it. "ah, the XSF is no longer neutral" That will not have any positive effects.

  155. ralphm

    pep. if you want to draft a change like that, we can discuss it more concretely. IMO

  156. ralphm

    and what Guus says

  157. Guus

    as to defining things - I'm not seeing the point, but I'm happy to discuss a concrete suggestion.

  158. pep.

    Who are we trying to please when we're afraid that the XSF is "no longer neutral"

  159. pep.

    (I bet that's exactly those I don't really care about)

  160. ralphm

    Cutting it short here. Let's pick this up for a next meeting.

  161. pep.


  162. ralphm

    Also the AOB will move to next week.

  163. ralphm

    3. Date of Next

  164. ralphm


  165. ralphm

    4. Close

  166. pep.


  167. ralphm

    Thanks people!

  168. pep.


  169. Ge0rG


  170. ralphm bangs gavel

  171. pep.

    Sorry Ge0rG I took all your time :p

  172. Ge0rG

    pep.: wasn't important anyway :

  173. Ge0rG


  174. Guus

    I think we need better time management than this

  175. Ge0rG

    it was just that I've recently impersonated the XSF and offered our resources for free.

  176. Guus

    also, can we please have agendas, as we agreed earlier?

  177. ralphm

    Guus: I'm sorry.

  178. ralphm

    Ge0rG: splendid

  179. pep.

    fwiw, I'm not so fond of defining something I have no stakes in. This neutrality thing is not on the website yet and I'm not going to try to promote it for you

  180. pep.

    I'd just like that we drop the ball internally once and for all

  181. ralphm

    unfortunately, you seem to be the only one so far that believes there's a ball to drop and we have a problem. Again, make a concrete proposal, and we will discuss it.

  182. Syndace

    To me it seemed like the board members agreed that the XSF is not 100% neutral in all matters, so I agree with ralphm that the ball is already dropped at least among Board members?

  183. pep.

    I'm not the one claiming that we are neutral

  184. pep.

    Syndace, might as well drop the word then

  185. MattJ

    Neither is anyone else, to such an extent as you seem to believe?

  186. pep.


  187. pep.


  188. Holger

    pep.: Isn't that a good topic for a broader mailing list discussion? I think I'd personally disagree with your goal (sorry) but I do get your point, and think your examples weren't bad to clarify it (i.e. I don't agree with your point being vague). I'd see value in clarifying these points.

  189. pep.

    Can you rephrase

  190. MattJ

    I see several examples of different kinds of neutrality that have been discussed in the past year, they are not all the same thing, and we don't have a single "neutrality" stance

  191. ralphm


  192. pep.

    MattJ, right, so that's even more confusing

  193. MattJ

    1) implementation neutrality, which as I said earlier, is the thing that was asked about in the members survey

  194. MattJ

    2) licensing neutrality, which was heavily discussed to death during the OMEMO debate

  195. MattJ

    3) political neutrality, in which some non-tech issues were recently discussed at board meetings, and what action the XSF should take, if any

  196. ralphm

    1) and 2) are explicitly encoded in our Mission and in XEP-0001

  197. MattJ

    A single person can have different views on each of these three "neutralities", and still be a member of the XSF

  198. ralphm

    For 3, if we can't get consensus in Board, we tend to ask our membership and/or wider community.

  199. pep.

    2) isn't about "neutrality", it's about being permissive, not about allowing any kind of license, right

  200. pep.

    See how that's also confusing

  201. ralphm

    2) definitely ties into neutrality in that we want *everyone* to be able to implement our protocols. Most of the OMEMO debate was exactly about this point.

  202. MattJ

    neutrality in that sense is that we should not exclude people from implementing the protocols we publish

  203. ralphm

    by applying a limiting license to the protocol itself (Signal), that invalidated that goal

  204. pep.

    ralphm, I still disagree wrt. the point of the OMEMO debate. I agree it has touched this subject of neutrality but I disagree that was the main purpose

  205. ralphm

    Of course others can have other angles, but the discussion was kicked off on this point particularly, by dwd

  206. pep.

    The purpose of the OMEMO debate to me was about saying "Hey if we allow specs to mandate GPL implementations, I don't have off-the-shelf pieces I can use anymore for my non-GPL product". And tbh, I couldn't care less about this specific point

  207. ralphm

    That quoted statement is internally inconsistent.

  208. Ge0rG

    pep.: well, it was about adding a dependency on something that only existed as a GPL implementation

  209. pep.

    MattJ, so neutrality of implementation still

  210. pep.

    Ge0rG, sure

  211. ralphm

    Non-GPL product developers would totally ok with implementing MEMO, if the spec would allow for this.

  212. pep.

    ralphm, how so?

  213. Ge0rG

    pep.: if there was a permissively-licensed protocol specification, adding it would be neutral.

  214. ralphm

    OMEMO, I meant from scratch

  215. pep.

    ralphm, yes and note that I'm not talking about OMEMO in the quote

  216. pep.

    Because it doesn't matter

  217. ralphm

    Indeed, we would reject all such protocols

  218. pep.

    I think you're missing my point. Anyway..

  219. Ge0rG

    pep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"

  220. pep.

    Or just ignoring it, dunno

  221. Syndace

    > Or just ignoring it, dunno cmon...

  222. pep.

    Syndace, I'm genuinely asking :/

  223. Zash

    Makes more sense to me if you think of it as the protocol and its normative references being incomplete and insufficient to implement the protocol.

  224. ralphm

    pep. yes, I have a track record on ignoring peoples opinions when they don't match mine, and always shutdown discussions

  225. pep.

    Ah well, that explains it :P

  226. pep.

    MattJ, so to me the "neutrality" that's been used around for years is really just about allowing anybody to implement our stuff, nothing less nothing more

  227. pep.

    It doesn't say anything about what we accept or we don't, who our protocols target etc.

  228. pep.

    (who we're doing all this for)

  229. Ge0rG

    that'd be #2 from the above list, then

  230. ralphm

    You raise a good point on not being explicit on who we develop protocols for.

  231. MattJ

    Then why are talking about our "neutrality" stance in the context of sponsoring a secure messaging summit? (which is implementation-agnostic)

  232. ralphm

    I think that is orthogonal to the neutrality thing.

  233. pep.

    MattJ, because it does seem all mixed up

  234. MattJ

    Clearly you think the "neutrality" thing *does* cover more than just implementation neutrality

  235. pep.

    Well I don't remember a clear statement anywhere so..

  236. pep.

    (and no I don't remember that one private survey from 2-3-4 years ago)

  237. ralphm

    Ok, in that case, let's assume that there isn't anything beyond that, until shown otherwise.

  238. pep.

    "Ge0rG> pep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"" now seeing this. And as much as I understand the difference, I'm not entirely sure it did matter in the thread. I can quote parts of it if you'd like

  239. Ge0rG

    pep.: well, it's a complex topic and I'm sure there were misunderstandings both in reading and in writing opinions.

  240. Ge0rG

    I like the three dimensions of neutrality that MattJ outlined above, and it probably wouldn't hurt to have some sort of Mission Statement Explanation that identifies our position, if any, on each of them

  241. pep.

    I think 1 and 2 are exactly the same

  242. Ge0rG

    I read #1 as giving money to developers

  243. ralphm

    No licensing is not the only possible issue. So are things like patents, copyright (on literal strings like with Signal), trademarks.

  244. Zash

    If you s/money/advertising space/ and then look at the software listing pages

  245. theTedd

    not to drag this on, but I interpret pep.'s point as being: it's impossible to be universally impartial, so the XSF should state in which directions it aims to be and what what actions it takes to pursue those aims

  246. pep.

    Anyway.. I still don't like the word "neutral", because most often it's a lie. Being neutral most often just means supporting the status quo. Be it when it comes to licenses (What's our impact in terms of what kind of implementation (licenses)'s got the most users?), politics (who are our direct users in terms of their number of users?), etc.

  247. MattJ

    theTedd, and as far as I'm concerned, we do, on a case-by-case basis

  248. pep.

    On what basis, what document should I refer to

  249. MattJ

    I wouldn't oppose some general document that summarizes our stance in certain areas

  250. MattJ

    But I'm not volunteering to write it, because I see other priorities

  251. MattJ

    Maybe this will get me unelected soon, but: I care relatively little about the XSF as an organization

  252. MattJ

    I think it serves as a decent steward of the protocol, but I think XMPP is bigger than the XSF

  253. ralphm

    The XSF is a means, not a goal.

  254. MattJ

    In terms of the ecosystem, and the directions XMPP needs to go in

  255. pep.

    Tbh if I didn't care about the XSF as an org I wouldn't be in board right now. It's not exactly going the way I want it (which is why I'm here), it's a huge time sink. If I only care about XMPP I wouldn't bother with the XSF

  256. pep.

    Tbh if I didn't care about the XSF as an org I wouldn't be in board right now. It's not exactly going the way I want it (which is why I'm here), it's a huge time sink. If I only cared about XMPP I wouldn't bother with the XSF

  257. theTedd

    who should I poke for a website issue?

  258. pep.

    (also emotional sink, exactly because it's not going the way I want it, and lots of resistance :))

  259. pep.

    theTedd, issue, or commteam, but ultimately board members and iteam also have commit rights

  260. MattJ

    The only thing an actual organization is useful for is holding IP (trademark, etc.) and channelling money... and I'm not sure the XSF is excelling at either of these things (though slowly improving)

  261. ralphm

    pep. What if you never get consensus in your favor?

  262. Kev

    I think the XEP series without an organisation wouldn't work.

  263. MattJ

    Kev, many open-source projects don't have an organization to back them

  264. Kev

    And I do think the XEP series, for its flaws, is still worthwhile.

  265. MattJ

    and they work just fine

  266. pep.

    ralphm, I'm probably gonna give up. It's crossed my mind quite a few times. And I'll let you be in piece (finally?) :)

  267. Kev

    MattJ: But they don't generally provide open standards.

  268. pep.

    I know I'm not the only one with this kind of opinions, but I'm the only one vocal about it

  269. intosi

    Open source and open standards are two vastly different domains.

  270. pep.

    So is free software

  271. theTedd

    all of those terms have become loaded, so different people understand them to mean different things

  272. pep.

    theTedd, https://thebaffler.com/salvos/the-meme-hustler I encourage you to read this

  273. pep.

    it was a good read

  274. ralphm

    pep. I would hate to see you go. You say there are others, but rough consensus only works if people speak up. I can see that arguing against the 'rest' can be tiresome. On both ends.

  275. Zash

    theTedd: It was mentioned elsewhere that https://bitbucket.org/mrtedd/compliance-badges/ has been lost to the gitbucket. Putting those up somewhere else would be nice if it could be arranged.

  276. theTedd

    pep., it looks long, but maybe later ;)

  277. pep.

    yeah it is long

  278. theTedd

    Zash, I'm going to update it anyway, so I'll fix it then

  279. theTedd

    on the website issue: xmpp.org/extensions/ has a broken link in the head -- <script src="/js/extensions-table.js"... should be "/theme/js/extensions-table.js"

  280. pep.

    If you can PR I'll merge it

  281. pep.

    (indeed it's borked)

  282. ralphm

    I agree with Kev on needing an org for standards development. If only for our IPR policy

  283. pep.

    theTedd, or I can PR if you don't want to do github, that's fine :)

  284. theTedd

    if you can pep., thanks

  285. pep.

    https://github.com/xsf/xmpp.org/pull/784 somebody to merge?

  286. pep.

    https://github.com/xsf/xmpp.org/pull/785 another.

  287. Zash


  288. Zash

    YOLO /me clicks button

  289. mdosch

    Zash: > gitbucket Hey!

  290. Zash

    Yes, I stole it. That's what it's called now.

  291. mdosch


  292. Ge0rG


  293. marc

    Ge0rG, just wondering if we would need more than 389 + a more or less general definition of jabber:x:data for a token challenge (as defined in 389)

  294. Ge0rG

    marc: I'm not sure. Are you speaking of data forms? We've had them in IBR already...

  295. Ge0rG

    This is not my core competence

  296. marc

    Ge0rG, yes, data forms

  297. marc

    anyway, so far 389 looks like a quite flexible solution

  298. Ge0rG

    Then we end up replacing data forms with... data forms?

  299. marc

    Ge0rG, the difference is that we have proper definition what data elements are necessary for a given "flow"

  300. marc

    like for 401 / token: provide a token and an username (optional when not defined by the token)

  301. marc

    and can be used automagically by a client

  302. marc

    and we can advertise features which is not possible atm