XSF Discussion - 2024-03-17

  1. junaid

    With XEPs that are actively and directly competing with each other, I feel we simply need to try and agree on the preferred way forward and then slowly try to deprecate the remaining. (Of course the feasibility of this is case-by-case)

  2. junaid

    > Tags would help there probably. I don't know if there is such a thing yet though If you're referring to string tags, then this is a possibility but I feel like many XEPs could easily get the same or similar tags. E.g. Everything that does supports/uses Omemo could get the "Omemo" tag, but then the "Omemo" tag will not reflect all XEPs competing with Omemo.

  3. singpolyma

    junaid: most of the overlapping xeps are experimental, so officially none of them is ready. but yes I agree I'd like to see less of that kind of thing

  4. moparisthebest

    Can't find the best without survival of the fittest

  5. singpolyma

    sure, but ideally we do that before assigning xep numbers ;)

  6. flow

    I am not sure that it matters much if the XEPs has a number or not…

  7. flow

    Also, sometimes you need overlapping specs (in the broadest sense), see OMEMO and OX

  8. singpolyma

    I think omemo and ox overlap only in broad concept. having both is very sensible

  9. flow

    right, that isn't to say we had people arguing that there should only be one

  10. flow

    right, that isn't to say we hadn't people arguing that there should only be one

  11. moparisthebest

    > sure, but ideally we do that before assigning xep numbers ;) Absolutely not ever, numbers are free, we literally have an infinite supply

  12. moparisthebest

    They need numbers so they are under clear IPR

  13. flow

    In general, I doubt that we, as standards org, can do more than letting the ecosystem decide which standard will survive, while of course trying to facilitate that there aren't multiple

  14. flow

    moparisthebest, that's an artifical limitation that could be lifted at any time. I-Ds also don't have numbers, yet the authors already agreed to certain things

  15. flow

    what I find more irritating is that it is absolutely not sensible to refer to XEPs by numbers when we already, at least, in theory assign short names to them, which we could use instead :/

  16. moparisthebest

    Naming is still one of the unsolved problems in computer science, numbers are easy

  17. L29Ah

    was it Stream Management or Session Management?

  18. L29Ah

    "sm" gee thanks ok

  19. L29Ah

    are sessions ever used for anything but the connection establishment ritual?

  20. singpolyma

    > > sure, but ideally we do that before assigning xep numbers ;) > Absolutely not ever, numbers are free, we literally have an infinite supply Sure, but giving numbers to uninmplemented things leads to this duplication and branding issue that we have

  21. singpolyma

    The benefit to a XEP being published with an official number is a sense of it being real and approved, and we can say as loudly as we like that experimental xeps are not real nor approved but no one outside this room will ever understand that, since it's not how basically any comparable process works

  22. moparisthebest

    Oh I feel like we rarely give numbers to things without implementations

  23. singpolyma

    moparisthebest: we literally did it at the last council meeting

  24. singpolyma

    I support this one, and I expect to see implementations very soon, but yeah we did

  25. moparisthebest

    But it's hard for more implementations to happen without a number because of IPR considerations

  26. singpolyma

    I've never heard of IPR considerations being a reason before

  27. singpolyma

    people don't implement without a xep because it's "not official"

  28. moparisthebest

    Which push xep does siskin and monal implement again? That's a problem

  29. singpolyma

    moparisthebest: why is it a problem?

  30. singpolyma

    it's published and in xep format even

  31. singpolyma

    eh, ish, I guess the format is missing some sections

  32. flow

    It's fine that stuff gets spec'ed and developed without having seen council, but we should probably work on making this stuff a) discoverable and b) located at a single place

  33. singpolyma

    we do. once it's ready it sees council, gets a number, and becomes discoverable in our single place

  34. flow

    I really meant right now

  35. flow

    before it sees council

  36. singpolyma

    that whole point is that before then it's not ready for wide consumption. so you don't want it to show up in the "big list of hundreds of xeps one must implement" people pretend exists

  37. flow

    I didn't say that it should show up there

  38. singpolyma

    I think if something is ready to be listed, it should see council and get a number

  39. flow

    and I am also not sure why its not ready for wide consumption when there already two implementations working on it. shouldn't be a problem if a third joins?

  40. moparisthebest

    singpolyma: what's the IPR on that spec? Is it patented or can you freely and legally implement it ?

  41. singpolyma

    moparisthebest: I mean, it's unpatentable, but I suppose I'm not your lawyer so don't take my word for it ;)

  42. singpolyma

    being submitted to XSF isn't a magic anti-patent bullet

  43. moparisthebest

    Everything is patentable

  44. moparisthebest

    Other problems include, what do you call it, how do you reference it, how is it versioned, what's the namespace etc etc

  45. singpolyma

    nothing about having gone through the XEP process changes possible IPR risks

  46. moparisthebest

    All problems solved by giving it a XEP number, simple

  47. singpolyma

    Sure, but if you're having those problem then it's probably time for a xep

  48. singpolyma

    when you're just collaborating on implementations you don't need to worry about such things usually

  49. singpolyma

    only once non-collaborators are also going to implement

  50. singpolyma

    at which point yes you need a process and versions etc and that's what a xep is for

  51. moparisthebest

    I think we are talking about different things

  52. moparisthebest

    As far as I know no one has ever had a thought in isolation and then submitted it as a XEP

  53. flow


  54. singpolyma

    > As far as I know no one has ever had a thought in isolation and then submitted it as a XEP AFAICT this is most xeps

  55. flow

    sadly, I think you are right

  56. flow

    however, I don't think that it should be that way

  57. flow

    when OX was developed, there where monthly meetings and calls for participations

  58. singpolyma

    or they had a chat with a few people about the idea first maybe, so not quite "in isolation" but without trying it out or anything

  59. flow

    and that was when OX didn't had a number yet

  60. moparisthebest

    >> As far as I know no one has ever had a thought in isolation and then submitted it as a XEP > AFAICT this is most xeps Which XEP was developed like that

  61. flow

    I really think pre-XEP spec'ing should be happen as transparent and welcoming as possible

  62. moparisthebest

    I think it is

  63. moparisthebest

    Most of them are discussed in here months to years in advance

  64. singpolyma

    every summit even I see action items like "I'll go write that XEP" based only on a half hour discussion of high level concepts at summit

  65. moparisthebest

    Half hour discussion != Isolation

  66. singpolyma

    I said that already above

  67. singpolyma

    "not quite isolation"

  68. singpolyma

    but certainly no implementation

  69. moparisthebest

    I find that an odd way to do it but that's ok, different people work differently

  70. moparisthebest

    If several people agree to implement after it's spec'd that's fine

  71. flow

    tbf, I think you both are right somehow. still, it would be nice if we tried harder to avoid to give the impression that XEPs are initially spec'ed in closed backrooms (it certainly felt like this has happened in the past)

  72. flow

    and I think we could change your process to accomodate and facilitate that

  73. flow

    and I think we could change our process(es) to accomodate and facilitate that

  74. flow

    SHOULD even

  75. flow

    maybe even MUST

  76. moparisthebest

    Like what? Propose something

  77. flow

    I have some notes here :)

  78. flow

    And I think I already have a mailing list post about a pre-number "incubating" state for XEPs

  79. flow

    but that was probably pre-corona

  80. moparisthebest

    Observing other standards orgs from the outside, XSF's seems by far the best to me

  81. moparisthebest

    Not to say it can't be improved of course, but better than most is a good place to start

  82. flow

    that doesn't mean we could try harder :)

  83. flow


  84. singpolyma

    microformats (and now indieweb) have always been the kings of open collaborative specification. Spend more words documenting use cases and lists of implementations and examples than on the spec itself. I'm not saying we need to go that far, but it's a good model to be aware of

  85. singpolyma

    I think the biggest red flag is when someone is trying to "think of all the use cases" a priori. That's how we end up with things like the old archive xep which no one implemented. Better to deploy something and find out from users what the use cases are

  86. moparisthebest

    Yes that's just "perfect being the enemy of good" no?

  87. moparisthebest

    What is a "microformat" ?

  88. singpolyma

    here is one http://microformats.org/wiki/h-card