jdev - 2024-01-06

  1. pep.

    Guus, what do I need to opt into your xmppnetwork thingy? I'm thinking jj.o (MUC) rather

  2. pep.

    Also, why are there nodes stuck to others. I see 3-4 really close to linkmauve.fr and the rest way further

  3. pep.

    Ah there's a prosody module

  4. Guus

    pep. strictly speaking, to 'opt in' (allow others to name your domain), your domain needs to have this feature in its disco#info response `<feature var='urn:xmpp:serverinfo:0'/>`

  5. Guus

    the position of the nodes is, as far as I can tell, randomly generated by the javascript library that's drawing the graph. I'm feeding it only the nodes (the circles) and the edges (which nodes are connected to each-other). It positions everything itself. If you reload the page, the graph typically looks different, which is why I think it is random-ish.

  6. Guus

    And yes, there's a prosody module. This will not only 'opt-in', but also expose the s2s connections of the local domain.

  7. moparisthebest

    If domains could opt in via DNS TXT record they wouldn't need server modules

  8. jonas’

    also complicates "client" implemenations though.

  9. jonas’

    also complicates "client" implementations though.

  10. Guus

    There's a gazillion options that could be different. It is what it is for now.

  11. Guus

    There's a Ejabberd module in the works at https://github.com/processone/ejabberd-contrib/pull/327 - in its current state, it only does the announcing of the feature (opt-in). Untested though. My erlang skills do not make it feasible for me to develop that module further - but if you desperately want to opt-in, you probably could use that.

  12. Guus

    There's a MUC specifically for discussing this tool at xmpp:xmppnetworkgraph@conference.igniterealtime.org?join

  13. singpolyma

    Oh, does the prosody module do the listing now?

  14. moparisthebest

    I didn't mean change it, just as an additional option only your tool would need to look up, but nice to see more modules anyway :)

  15. Guus

    singpolyma; yes - it should be feature-complete - until we think of new features.

  16. singpolyma

    Guus: nice. I'll check it out

  17. Guus

    moparisthebest: there is something to more explicitly announce the opt-in thing. It feels strange to tie that into the capability of publishing this data yourself - but for now, it'll do.

  18. Guus

    singpolyma: let me know if it works for you. This was my very first Prosody module...

  19. singpolyma

    Guus: if I change the domain or node name I assume it will publish there but your tool won't find it?

  20. Guus

    singpolyma: I believe I've made an effort to implement this - but it is completely untested.

  21. Guus

    The pubsub coordinates should be advertised as an URI in your service discovery info, which should be picked up by the website's tool ... lots of 'shoulds' in that sentence though.

  22. singpolyma

    aha, yes, it seems to publish the service and node as part of the disco stuff

  23. Guus

    (I'm actually trying to see if I can add a quick DNS TXT lookup for moparisthebest ... suggestions as to the format?)

  24. singpolyma

    as one field with an xmpp uri instead of two fields, but meh

  25. Guus

    oh, the DNS TXT is pointless without updating the modules, as they won't report anything that my tool would now accept. Nevermind.

  26. Guus

    singpolyma: I _had_ two fields, then someone meh'ed that, making me change it to one field.

  27. singpolyma

    haha, ok. Seems suboptimal to me but it's invisible metadata so barely matters

  28. Guus

    although having one URI to reference one coordinate seems to make sense to me. It'll be harder to parse, true, but it's ... one reference.

  29. singpolyma

    Looks like you create the node with persist_items off -- not sure how that works for your tool to then get the full list?

  30. moparisthebest

    Guus: put it at a subdomain starting with _, maybe like _xmppnetworkgraph.example.org to opt in example.org ?

  31. Guus

    singpolyma: I'm not actually sure how Prosody behaves. Openfire will cache the last item, allowing it to be looked up. In any case, my tool will subscribe, allowing it to receive the data when your server broadcasts it.

  32. moparisthebest

    content.... Maybe just "optin" or... Whatever

  33. singpolyma

    Guus: oh I see, right because you're publishing the whole list every time as a single item instead of one item per thing

  34. Guus

    singpolyma: indeed.

  35. singpolyma

    so it'll catch up on next publish

  36. singpolyma


  37. Guus

    doesn't prosody keep the last published item in memory, even without persisting it?

  38. singpolyma

    no idea. I never use pubsub with persistence off

  39. singpolyma

    > -- When the instance of Prosody hosts more than one host, the other hosts can be thought of as having a 'permanent' s2s connection. hmm -- I guess so? A lot of my vhosts have no logical connection to each other

  40. Guus

    XEP-0060 says: > A service MAY cache the last item published to a node (even if the "persistent-items" option is set to false); if it does default "cache-last-item" to true, it SHOULD send the last published item (or notification thereof) to subscribed entities based on configuration of the "send_last_published_item" field. It doesn't _really_ matter if Prosody does allow for that, as it'll catch up at the next publication, as you said.

  41. Guus

    Yeah, I know of no good way to assert if Prosody-internal vhosts have a connection to each-other. Devs implied that that wasn't the case. I don't know of another solution to either assume they're all connected, or not.

  42. singpolyma

    sure. it's just for fun mostly anyway, not like we're gonna rely on this data being pristine

  43. Guus

    Oh, I'm doing more nasty stuff with it. I'm aggregating subdomains, for example

  44. Guus

    pubsub.example.org, chat.example.org, conference.example.org --> that's all 'example.org' to me.

  45. Guus

    The graph immediately started to look very weird without that.

  46. Guus

    There's also little guard against domains submitting incorrect data. I'm not accepting data from pubsub services that do not belong to the domain that they're reporting data for - but that's about it.

  47. MattJ

    Guus: how do you determine that they are subdomains?

  48. Guus

    String-based: subdomain endswith domain

  49. MattJ

    I remember an Openfire bug from many years back when it thought matthewwild.co.uk was a subdomain of co.uk

  50. MattJ

    And then tried to connect to co.uk

  51. Guus

    Wouldn't it be great if that would actually succeed :)

  52. MattJ

    So I host a lot of *.snikket.chat domains, will it correctly display them as separate servers?

  53. Guus

    yes. The downcasting is only for a set of commonly used subdomains for components ('pubsub', 'conference' etc)

  54. moparisthebest

    Mr. Pubsub is very upset

  55. Guus

    Not as upset as the Null family.

  56. singpolyma

    I will add a pubsub service somewhere for my domains to publish to next time I am near my dns creds

  57. moparisthebest


  58. Guus

    singpolyma: nice - but you'll need a pubsub service that is a subdomain of each of the domains that you're publishing for (to get around the aforementioned guard against malicious data entry)

  59. Guus

    at least until I come up with and implement a better guard.

  60. singpolyma

    probably if you want a general heuristic you could see if the domain is a subdomain of another you actually have data for. that way it wouldn't fold up snikket.chat unless snikket.chat itself was on the list. that's probably right 85% of the time?

  61. singpolyma

    Guus: oh, really? it has to be a subdomain of the domain? hmm

  62. singpolyma

    that's less ideal

  63. singpolyma

    How could it be malicious when I publish my own service and node myself, so you can know that's what I meant to use?

  64. Guus

    for now, yes. That was based on a similar 85% right assumption.

  65. Guus

    I'm trying to trace back my reasoning ...

  66. Guus

    oh, it's a stop-gap measure, as I hadn't built in a check to see if the pubishing domain actually is equal to the domain that's advertised as the authoritive domain for the data that's published.

  67. Guus

    ... which I can probably build rather quickly...

  68. Beherit

    Just be clear, it did mean this ironic ### XMPP SUMMIT 26 **Important reminder** Dear all, one month to go until our annual summit takes place ✨ We are all looking very excited forward to this! We just published a blogpost with some details: https://xmpp.org/2024/01/xmpp-summit-26/ Please help to spread the word. Thanks for all who have signed up already. We are almost 30 people, this is really great 🤯. By latest *Monday, 15th January* we kindly ask you revisit the following points: - Sign-up if you haven't yet - Please update your entries in the list (incl. removal if you do not participate) - Also announce you membership and dinner participation (new columns) - Join the Summit chat room or summit maillist (see blogpost) - Sign-up if you want to give a talk / presentation up to 30 minutes. - We are also happy to see listing if you are remote participating In that regard refer to the wikipage: https://wiki.xmpp.org/web/Conferences/Summit_26 If there is more interest for individual sponsoring of the event or dinner that is of course also appreciated. Looking forward to see you in Brussel 🇧🇪

  69. Guus

    singpolyma: I've now dropped that restriction of having a pub/sub service be a subdomain of the domain that's being reported on. Instead, The code now verifies that the service reporting data is the same service as the one that's identified in the disco#info of the domain.

  70. Guus

    Which caused a major refactoring, so you're on the hook for helping me test this :)

  71. singpolyma

    Guus: nice!

  72. singpolyma

    Promise I will

  73. Guus


  74. Guus

    (this is a much better approach - it also allowed me to drop a few hard-coded assumptions)