XSF Discussion - 2022-09-23


  1. bhavy

    Hello everyone, can anyone help me with creating the wiki account?

  2. moparisthebest

    Alex perhaps^

  3. Alex

    You can send me an email with your preferred nickname to gnauck@gmail.com and I can create an account later today in my evening

  4. bhavy

    Alright, thank you.

  5. Guus

    I can do it _right now_

  6. Guus

    I just need your preferred nickname and an email address

  7. bhavy

    > : I can do it _right now

  8. bhavy

    Now I am confused, I already sent the details to sir @Alex

  9. bhavy

    Should I send it to you too right now?

  10. bhavy

    Should I send it to you too right now sir @Guss ?

  11. Guus

    bhavy: I have created a new account for you on the wiki. You should have received a confirmation email in your mailbox.

  12. Guus

    Alex and me can both create these accounts. I just thought I'd help you immediately, since I was available now.

  13. Guus

    But then, I got dragged into a meeting and failed to respond to you, causing confusion. Apologies :)

  14. bhavy

    Ok, thank you.

  15. bhavy

    > bhavy: I have created a new account for you on the wiki. You should have received a confirmation email in your mailbox. Yes, I did thanks once again :)

  16. edhelas

    goffi, I just had a look at Event

  17. edhelas

    It's quite interesting but I'd really prefer to break it down in several small xeps, lots of features seems to be a bit optional and I'd prefer to have different namespaces for those features

  18. edhelas

    I'm always afraid of big xeps like that because you tend to have many different implementations level in the wild

  19. goffi

    edhelas: it's not like pubsub, except <start/>, <end/> and <name/>, everything is optional. It's just metadata that your client show or not, but it doesn't really hurt to not have them. While I agree that some feature could be split in sepate XEP (mainly RSVP actually), the issue with doing many XEPs is that it increases the workload, and I have already an heavy enough load.

  20. goffi

    and in the case of events, I'm not convinced that it really worth it.

  21. goffi

    for pubsub attachments it may make more sense

  22. singpolyma

    Is there an XML of vevent like for vcard4?

  23. Zash

    singpolyma, https://www.rfc-editor.org/rfc/rfc6321

  24. edhelas

    On my side I was more thinking of simply attaching xCal to Atom publications, quite simple to do

  25. singpolyma

    edhelas: yeah, that sounds ideal

  26. edhelas

    That would be perfect for https://mov.im/?node/pubsub.movim.eu/berlin-xmpp-meetup

  27. edhelas

    You create a publication and configure an event for it, like attaching a picture or a link

  28. edhelas

    And that's it

  29. edhelas

    In Movim I was planning to convert the xCal to iCal and allow then integration with mobiles/desktop agendas

  30. edhelas

    But it doesn't solve many of the topic addressed by goffi Event xep

  31. Zash

    Oh, new XEP?

  32. singpolyma

    I will have to read the xep before having an actual opinion

  33. goffi

    this XEP convert what I've been experimenting for years with libervia, and was necessary to convert ActivityPub events (from Mobilizon) in the gateway

  34. goffi

    it's staighforward to convert it to iCal or whatever, not a problem.

  35. goffi

    anyway I have to go now, afk

  36. Zash

    goffi, were you aware of RFC 6321?

  37. goffi

    Zash: RFC 6321 is IMHO making the whole thing far more complex and difficult to implement, with its own set of data types and metadata. My proposal uses XMPP mechanisms and data specifications: geolocation is XEP-0080, file references are XEP-0447, RSVP is XEP-0004 + XEP-0470 comments are simply a link to a XEP-0277 node, permission are managed with pubsub permissions. Most of that is probably already implemented by clients and specified, no need to find a xCal/iCal parser (and it's easy to convert if necessary is ones want to export data).

  38. goffi

    Also RSVP mechanism is based on existing XEPs and extensible with data forms. It would be more complicated to adapt an other xCal IMHO.

  39. singpolyma

    Reusing is good, which is the main thing about using xcal. Reusing other xeps is also good. Main thing is to avoid new xmlns strings where possible

  40. Zash

    All I want is a motivation to explain why existing things were not reused.

  41. Zash

    Sometimes it makes sense. Sometimes we just end up extending it until the prior existing thing has been reinvented.