XSF Discussion - 2021-08-06


  1. wurstsalat

    https://spacecloud.one/upload/8914a13e-7b6b-4d73-9ca5-e186310700a4/software_clients.png

  2. wurstsalat

    small teaser for the software listing (data was provided by Link Mauve)

  3. Kev

    That does look quite good, thank you.

  4. emus

    I think its awesome!

  5. wurstsalat

    Ge0rG, re compliance levels: wouldn't it be better to have "Basic" instead of "Core"? that way we would have "Core: Basic" instead of "Core: Core"

  6. wurstsalat

    but maybe that depends on Badge design anyway

  7. Kev

    I think the value in advertising compliance levels is limited, but there we go. Especially self-claimed compliance levels, which are likely to be lies :D

  8. moparisthebest

    easy to spot though

  9. emus

    Another question is also if those terms really help newcomers

  10. Kev

    I think, honestly, that they provide little value on that page, but I expect to be in the minority there.

  11. Sam

    I think the value in badges (even if they're lies) is just to advertise the compliance suites. If one person lies, but another person sees it and says "oh, neat, I want that badge too" and goes and implements a more compatible messenger, that's a win

  12. Ge0rG

    wurstsalat: "Basic Core" sounds weird as well. I just treated it in a way that "Core Core" becomes just "Core"

  13. jonas’

    Core²

  14. Ge0rG

    jonas’: sounds like Intel marketing

  15. jonas’

    my thought exactly :)

  16. larma

    I also do see issues with displaying compliance data that way. I'd rather have certain "features" that might not perfectly match compliance suite categories. For example, a client could be A/V advanced compliant when only supporting audio-calls (which also perfectly makes sense if the client is meant to run on a device without a screen suitable for videos) On the other hand, features like "omemo-support" might be more relevant to some users than that a clients is "advanced im compliant". Maybe it makes sense to first get some insights which features would be interesting to users of this page and then display those. I could imagine this can also be done using icons instead of text, so that this won't be displayed as a big list in the end.

  17. MattJ

    FWIW I was planning to do something like this

  18. MattJ

    XEP support isn't really relevant to users at the end of the day

  19. Daniel

    How about displaying the data we have and migrate to better data once we have that

  20. MattJ

    It's a good baseline - e.g. we probably want to simply not list clients prominently that don't support the basic compliance stuff, it's indicative of incomplete or legacy implementations (Pidgin supports A/V calls and OMEMO...)

  21. wurstsalat

    Daniel, thanks

  22. Daniel

    Otherwise we'll never display anything

  23. MattJ

    I'd rather display nothing than what is currently shown under "compliance"

  24. MattJ

    As in, just don't show the compliance stuff, but we can use it as a filter

  25. MattJ

    I'm in no way suggesting delaying this update :)

  26. MattJ

    Just don't spend all our time debating "Basic" vs "Core Core"

  27. MattJ

    Because I don't think it's useful information

  28. MattJ

    (to end users looking for an IM client)

  29. wurstsalat

    yeah, filtering by AV for example could be really useful via checkbox (I could keep that data per item, but hidden)

  30. moparisthebest

    I'd argue the type of end users who visit xmpp.org to look for an IM client are a different type of user than the average user

  31. MattJ

    But A/V alone is hard to define... Pidgin does A/V

  32. wurstsalat

    but does it do AV 2021 ?

  33. MattJ

    Ah there's already an A/V section in the latest compliance suites, I forgot about that

  34. wurstsalat

    detecting omemo via doap would be easy as well :)

  35. emus

    > MattJ escribió: > FWIW I was planning to do something like this > XEP support isn't really relevant to users at the end of the day Yes, and thats why I think - first we should have some recommendation/guidance - second, maybe list XEPs and features in something like a detailed / expandable view What I defintivly disagree about, is again doing nothing, or leave it as it is. I expect almost everyone new to XMPP is asking for at least some orentation . And we should provide this, even we risk outdated or not 100% accurance. I'm sure we will find ways to improve Well, and dont "forget": This a decentral network, I think we have to put *extra* efforts to guide people. This is a downside of federation I think. But it is also not too hard to solve. I think therefore we should have guidance. Details tbd

  36. MattJ

    You don't need to tell me :)

  37. emus

    > Daniel escribió: > How about displaying the data we have and migrate to better data once we have that That could be a first step I think. But it is also okay to help with communicating instead of only shown xeps

  38. emus

    > MattJ escribió: > You don't need to tell me :) No, I just agreed with you and then continued writing 😅

  39. emus

    was meant for everyone

  40. emus

    > wurstsalat escribió: > detecting omemo via doap would be easy as well :) Lets have a call next week maybe to discuss the categories?

  41. millesimus

    Maybe the page should (at first) not aim for the new average user, but for new advanced users: helping the tech-savy but new users to learn on xmpp and to help their less tech-savy contacts.

  42. wurstsalat

    at the moment I'd like to focus on getting Link Mauve's (and other people's) effort around DOAP on the website. if that's just name, description, and logo for now, that's a first step. once this is running, it's easy to derive and add new categories.

  43. lovetox

    https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format

  44. lovetox

    unique sortable ids !!

  45. lovetox

    we need this for mam :D

  46. MattJ

    There are a few algorithms around already like this

  47. MattJ

    Nice to see some standards though

  48. moparisthebest

    like a simple counter?

  49. MattJ

    Counters are problematic, you have to maintain the state forever (i.e. not unique if you reinstall your server), they don't play well with distributed setups (in XMPP's case that would be any clustered deployment), etc.

  50. MattJ

    So most are based on timestamp + counter

  51. moparisthebest

    ah yes, I was mainly talking about the abstract: > A common case for modern applications is to create a unique identifier for use as a primary key in a database table.

  52. emus

    does anyone have time to check the docker deploying? i dont know why the newsletter does not get published

  53. MattJ

    I'm not at my laptop right now... possibly later this evening if nobody else figures it out first

  54. MattJ

    I thought it just worked last time

  55. emus

    I think I found the error

  56. emus

    But thanks! I'll let you know

  57. Link Mauve

    wurstsalat, maybe we could sort by compliance suite support, but not display that at all for now.

  58. Link Mauve

    IIRC that’s what I wanted to do with it.

  59. wurstsalat

    Link Mauve, you mean sorting by being compliant to core (core level or advanced level) or not?

  60. wurstsalat

    I see now that the data you provided was already sorted (kind of)

  61. wurstsalat

    https://spacecloud.one/upload/5c0cefec-abec-401f-983c-f41b4fd88a26/software-features.png

  62. wurstsalat

    example of how it could look with feature labels (AV in Conversations)

  63. MattJ

    wurstsalat, what if you used something like https://matthewwild.co.uk/uploads/check-core.svg and https://matthewwild.co.uk/uploads/check-advanced.svg in those badges?

  64. Sam

    huh, neither of those render on my machine. Time to dig into SVG weirdness I suppose.

  65. Sam

    oooh, or they do, but Firefox sticks them over a white background by default. Good job Firefox.

  66. wurstsalat

    Sam, Inkscape displays them fine

  67. wurstsalat

    same in Chrome

  68. Sam

    Even in inkscape I thought they were broien for a moment

  69. wurstsalat

    MattJ, I'll give it a try!

  70. wurstsalat

    https://spacecloud.one/upload/c61dcd6d-4f1b-4557-8952-013e2b7eaa8b/software-av.png

  71. wurstsalat

    MattJ, ^

  72. Link Mauve

    wurstsalat, yes, the JSON is currently sorted by existence of a DOAP file first, then alphabetically.

  73. Link Mauve

    I’m open to changes there.

  74. Link Mauve

    Such as advertising clients with audio/video support first, or something like that.

  75. wurstsalat

    sounds like a good start so prioritize those with a doap file. I guess all clients supplying a doap file also have minimum Core Core :)

  76. wurstsalat

    s/so/to

  77. Sam

    As previously stated: I disagree. Having a doap file is not a good indicator of anything except a willingness to dig through XML schemas.

  78. Link Mauve

    Core core is quite easy to reach, implement the 6120 RFC (not even 6121 so you don’t need to support e.g. retrieving the roster), TLS, disco and caps, that’s it.

  79. Sam

    And the use of a static site generator that can easily generate XML or the willingness to hand-roll XML.

  80. Link Mauve

    Sam, aside from you, I haven’t heard of any request for a generator so far, given most of the burden will be in maintaining the list of the features you support, not in copy/pasting the initial version from another project.

  81. Link Mauve

    And we already went through that on list, there was no other opposition to DOAP-the-format either.

  82. Sam

    We've been through this. I already have a list, but no easy way to convert them to doap and I don't want to maintain two lists and two sets of tooling. I also do not want to just copy/paste. I've tried that and ended up with broken stuff before.

  83. Sam

    I still think we shouldn't use it at all, but this is a different thing: should it be an indicator of higher quality software that needs to be displayed at the top, and I'm saying the answer is "no".

  84. Link Mauve

    Which format is your current list in?

  85. Link Mauve

    Sam, here it isn’t about being intrinsically higher quality, but about providing more information that is useful to the website.

  86. Sam

    Link Mauve: it's in my static site generators format (I guess it's YAML spread out over a handful of files). There is no way to generate valid XML from the static site generator.

  87. Link Mauve

    As in, a less terse list than this one: https://xmpp.org/software/clients.html

  88. Sam

    I mean, I could make up templates that sprintf XML, but that always ends the same way.

  89. Link Mauve

    Which is absolutely horrible for new users.

  90. Sam

    So let me submit a PR to edit my clients bubble or whatever with the info, I don't see why we need to try to do some weird machine-readable automation for this and force all clients to use our thing.

  91. Sam

    But if we do, I definitely don't think "willing to do a bunch of steps the XSF wants" is a good indicator that means the thing should be shown at the top.

  92. Link Mauve

    Sam, do you also commit to maintain the list at JabberFR, at Wikipedia, at every other website that might want to provide the same data?

  93. wurstsalat

    Sam, all client cards in my examples are built from the data each doap file provides

  94. Link Mauve

    It’s not just about the XSF, it is about providin a machine-readable description of the features of your project, of every XMPP project ideally.

  95. Sam

    Link Mauve: the XSF has no reason to care whether I maintain the list on its website only or on its website and Wikipedia.

  96. Link Mauve

    No indeed.

  97. Link Mauve

    But this isn’t about the XSF, it is about XMPP.

  98. Sam

    That's fine, I still think you're wrong and DOAP is the XSFs usual over engineering, but I'm not trying to restart the argument over using it, I am just arguing that in a world where I'm overruled and we're using it we should also provide a local alternative.

  99. Link Mauve

    The XSF may use this data on its website, and the feedback I’ve received was generally very favourable to that.

  100. Link Mauve

    these* data?

  101. Sam

    "this data" is fine. Data is a group plural or whatever that's called

  102. Link Mauve

    Sam, you could propose to extend the xmpp.org JSON if you want.

  103. Link Mauve

    I did that with the DOAP URL, right now that’s the only place where DOAP is used at the XSF, in three JSON files.

  104. Sam

    What's the xmpp.org JSON? Is it documented anywhere?

  105. Link Mauve

    Sam, yes, at https://github.com/xsf/xmpp.org/tree/master/data

  106. Sam

    oh yah, this stuff. Let's do that.

  107. Sam

    I mean, I don't love that either, but sure, if it means we don't only prioritize clients that happen to use certain tooling and who have authors who want to read a bunch of XML stylesheets or whatever then fine.

  108. Sam

    schemas rather; doesn't matter.

  109. Link Mauve

    I still don’t think it makes sense to duplicate information between the project’s website and xmpp.org, and JabberFR, and Wikipedia, and every other website talking about XMPP stuff.

  110. Link Mauve

    And having a single source of truth is easier for everyone.

  111. Sam

    I don't disagree with that

  112. Link Mauve

    So I’m generally against extending this JSON format, I’d rather remove information duplicated with DOAP (platforms for instance).

  113. Sam

    However, not everyone will be able to generate doap so if you're going to do that (even if you used a sane format that I agreed with too, this isn't about doap in particular) not everyone will use the same tooling, or even have control over their website (think auto-generated documentation style things from comments being the only website) so we should also support some way to edit it locally for those people instead of just insisting that everyone use our undocumented data format and assuming they can all do so

  114. Link Mauve

    If a project comes to us about not being able to host a file on their web server, for instance because they don’t have one, I see no issue with hosting it at xmpp.org instead.

  115. Link Mauve

    Sam, note that it is now documented, in XEP-0453.

  116. wurstsalat

    I'm offering help for every project wanting to create their own doap file

  117. Link Mauve

    Same here.

  118. Sam

    Okay, that problem is at least solved then. I still think our use of DOAP is an embarassement and we should be ashamed of it, but at least we're not entirely screwing over everyone who can't conform to our tooling

  119. Sam

    Thank you for allowing them to be hosted on the XSF's site or wherever.

  120. Link Mauve

    (I have no authority on that, besides being a member, mind you.)

  121. Link Mauve

    If DOAP is good enough for GNOME, CPAN, Pypi, and probably many other collections of projects, I don’t see why we should be ashamed of it here.

  122. wurstsalat

    heh, look, there is a generator (for the generic fields at least) https://projects.apache.org/create.html

  123. wurstsalat

    and a validator as well

  124. Zash

    Didn't I make a tool too? CSV to DOAP is easy

  125. MattJ

    We already discussed hosting DOAP files in our repo for projects that need that. It's no worse than the current situation, but it's of course better for everyone if project maintainers have direct access to update the file

  126. MattJ

    wurstsalat, I think the icon is an improvement btw, though I'd move it to the left of the text (bikeshedding, I know), thanks for adding it :)

  127. MattJ

    Looking forward to getting this deployed

  128. wurstsalat

    MattJ, yeah I tried both, not sure :)

  129. Link Mauve

    Same, I’m pretty excited this is finally happening!

  130. Pete

    Hi, just want to point out that the link to RFC7622 on the Overview page of xmpp.org is giving me 404

  131. Link Mauve

    Pete, thanks for noticing! I proposed this change: https://github.com/xsf/xmpp.org/pull/947

  132. Pete

    Nice! I admit I tried to look thru the repo to see if I could spot an obvious error. I didn't think it would be acceptable to change the links to be offsite

  133. Link Mauve

    Pete, I grepped for 7622, and the two other pages linking to this RFC already used that link, so it’s probably fine. :)

  134. Pete

    Ah. Seems like linking to ietf directly would be preferable to maintaining a separate list of RFCs anyway, but there must be a reason

  135. emus

    MattJ, I think there is still no deployment 😕