XSF Discussion - 2024-02-06


  1. moparisthebest

    guus.der.kinderen: it's a very different script is my point

  2. moparisthebest

    No one is going to waste time on it unless it's definitely going to be used

  3. moparisthebest

    https://burtrum.org/up/065bd961-5d90-43a3-b183-857942b65b46/zb2rhmm8p8uGY71S4C1UHesAWwsAMxbRdgeUkbnbhfpYhZijD.jpg

  4. moparisthebest

    Now I'm getting SEO spam for xmpp.org ? I can't even...

  5. moparisthebest

    Did they scrape the wiki or what I wonder, anyone else?

  6. MattJ

    moparisthebest, I received the same email

  7. goffi

    ralphm: I'm planning to work on file sharing with hierarchy, something similar to XEP-0214 but using XEP-0447 and with proper permission (that's one of the major problem I had with pubsub collections, permissions are not managed the way I think they should be). At the summit you said that pubsub collections should be avoided, but that's a similar feature that I need. So what do you recommend, try to fix pubsub collections or start from scratch an other method?

  8. ralphm

    Does anything actually implement XEP-0214?

  9. goffi

    I don't think so.

  10. goffi

    There is XEP-0329 (that I've implemented in Libervia) which has a hierarchy for file sharing, but there is not all the pubsub mechanism, and I would like to be noticed of new/deleted/modified files.

  11. ralphm

    The biggest issue I have with collection nodes (other than maybe the root node), is that it is very tedious to set up the collection and the nodes that belong to it and the publishing, if the primary thing you want is to subscribe to a certain set of events that are associated with different nodes. In many cases, it would be better to not have explicit publishing, and the nodes just "existing" and allowing subscriptions based on content, rather than by name. Basically https://xmpp.org/extensions/xep-0060.html#impl-content. This also makes it easier to apply whichever permissioning you need without being tied down by the collections model.

  12. goffi

    You mean a subscription on different nodes at once based on content? I'm not sure to understand it well. Let's say I want to be notified of new files within a certain directory, how would I do that exactly?

  13. goffi

    Also content based subscription won't work with e2e encrypted nodes.

  14. ralphm

    So, for content based filtering, as an example, imagine subscribing to the root node, and providing subscription options that reflect a search query. This could filter on file name or any other attribute on that file. Maybe even a full text search on the contents or an AI generated summary of what's in a picture/video. All application specific, usually. And then when the backend finds a match, it sends out notifications for those matches. This might be on any node (this is the root node you've subscribed to).

  15. ralphm

    But if you control the backend anyway, you can also retain the hierachical setup of collections, but not have explicit setup and publishing. You'd just provide a pubsub interface on top of your filesystem, send out notifications when appropriate, and manage permissioning behind the scenes.

  16. ralphm

    I suppose the XEP-0214 model could work, too, but it seems cumbersome.

  17. ralphm

    As for e2ee nodes, I never thought about that, t.b.h.

  18. ralphm

    E2ee has drawbacks and one of them is you don't get to do fancy stuff on the backend. You can't have it all :-D

  19. goffi

    You're speaking about a root node, so that's still with pubsub collections, right? I got the filtering thing, it was just not clear how to get notifications for several nodes at once (but with root node it's clear). As for e2ee, in this case we can only get new items/items retractions notifications, which is already good to know, then we get the metadata and decrypt in the client to do fancy stuff.

  20. goffi

    My main issue with pubsub collections was that leaf node permissions were ignored in favour of parent collection node.

  21. ralphm

    Well, sure, the root node is a default collection that includes all nodes. All other nodes are explicit and I don't like the model.

  22. ralphm

    But if you control the backend (i.e. not rely on a generic pubsub service) than you can do whatever permissioning you want.

  23. ralphm

    But if you control the backend (i.e. not rely on a generic pubsub service) then you can do whatever permissioning you want.

  24. goffi

    I do control the backend, but I would like to have something standard so others can implement it too.

  25. goffi

    Seeing that there have been several attempts from different people to share files and their hierarchy, I suppose that there is a need.

  26. goffi

    I count at least XEP-0135, XEP-0214 and XEP-0329.

  27. ralphm

    Yeah, all good protocols come in three tries

  28. hook

    Hi. I’m browsing https://xmpp.org/software/software-comparison/ and there’s something that confuses me in the table.

  29. hook

    When adding software to the comparison table, it does not make a difference whether it’s server or client software. I suspect some XEP apply to clients and some to servers and some to both.

  30. Guus

    I hadn't seen that page before. Yeah, it allows you to mix different types of projects, which does not seem to be useful. I'm guessing this was easier to implement.

  31. hook

    So it might be easier to understand and compare (esp. for someone not intimately familiar with XMPP and XEP) if the fields that are not applicable would be marked as such. Let’s say XEP-0ABC applies only to servers, then it makes no sense that all clients seem like they don’t support that XEP – it looks than like it’s a feature that works on some servers and on none of the clients, “ergo essentially useless”.

  32. hook

    It might make sense to grey out those fields or introduce a “N/A” sign for such cases.

  33. MattJ

    The XEPs do not carry metadata that indicates whether they apply to clients or servers

  34. hook

    > I hadn't seen that page before. Yeah, it allows you to mix different types of projects, which does not seem to be useful. I think it’s still super useful esp. for XEP that need support on both clients and servers, so you want to use a certain functionality you can find the right combo.

  35. hook

    > The XEPs do not carry metadata that indicates whether they apply to clients or servers That’s metadata, but metadata can be either added to XEPs or to an external index. But can it be inferred from all XEP if they need to be implemented on the server and/or client side?

  36. pep.

    Inferred, probably hard.

  37. pep.

    Added as metadata, yeah certainly

  38. MattJ

    That's why the compliance suite checks are more useful generally, unless you know what you're doing

  39. MattJ

    (because they are already organized into what clients/servers should support)

  40. hook

    > Inferred, probably hard. I didn’t mean programmatically inferred …just that if all XEP are clear in their language that they apply to server, client or both. I’m wondering if they can even be categorised as such (I assume yes)

  41. hook

    MattJ, you mean _XEP-0479: XMPP Compliance Suites 2023_?

  42. MattJ

    More precisely, I mean that https://xmpp.org/software/ lets you filter by compliance level

  43. MattJ

    Which is automatically calculated from the latest compliance suite

  44. hook

    Ooooh, so it does.

  45. hook

    Sweet.

  46. hook

    BTW, is that list of software up-to-date with the XEP support? I wonder, because Metronome is listed as not having even Core IM compliance.

  47. MattJ

    It's up to software authors to provide that info in a DOAP file in their repo