Modern XMPP project discussion - 2024-03-26


  1. rom1dep

    > No I'm just focusing on having reliable federated video calls Well, I don't know about your experience and set-up, I can only talk about my own experience, which is; I self-host XMPP for family & friends (on an ejabberd instance, running on the smallest dedicated server one can get), and I spend several hours a week doing A/V calls, several of which are federated (I've got a few contacts on quicksy and other servers), and it just works great, I hear no complaints.

  2. edhelas

    > > No I'm just focusing on having reliable federated video calls > Well, I don't know about your experience and set-up, I can only talk about my own experience, which is; I self-host XMPP for family & friends (on an ejabberd instance, running on the smallest dedicated server one can get), and I spend several hours a week doing A/V calls, several of which are federated (I've got a few contacts on quicksy and other servers), and it just works great, I hear no complaints. Which clients are you using ?

  3. Menel

    I'm doing A calls mainly with conversations, on prosody, and eturnal, also small vps. Works always. Quality issues occur in bad networks. But in these cases it's not worse then with signal or whatsapp. (tested that)

  4. sch

    Would it be reasonable to have support for browsing node content of JIDs that utilize PubSub nodes? I think it would be beneficial to open a chat window (of chat and groupchat) and to browse content that is loaded on its PubSub, if available. The contents may be "group rules", "important notes", "recently shared media" etc. Example case: Uploading to a PubSub node of an office groupchat a letter and attaching audio recording and documents of yesterday's directorate minutes that need to be approved and reviewed by participants of the groupchat. I think that PubSub would be useful for doing this, instead of notifying every member or posting about it in the groupchat every now and then, and instead of uploading the data to an HTTP service and consequently opening a web browser to get that data.

  5. sch

    What do you think of this?

  6. sch

    What do you think of this idea for viewing PubSub with chat clients?

  7. MattJ

    sch: like Movim?

  8. sch

    Yes, but with lesser emphasis on PubSub.

    🤔 1
  9. sch

    Because this is namely a chat client.

  10. edhelas is hurt

  11. sch _hugs_ edhelas

  12. sch *hugs* edhelas

  13. sch

    Of course, this would indeed make chat clients to behave more like Movim.

  14. MattJ

    I think that's up to individual clients

  15. sch

    Yes, of course.

  16. MattJ

    I'm not a fan of the bottom-up (protocol first) approach to client development. It didn't produce clients with mass appeal in the past.

  17. MattJ

    So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support

  18. MattJ

    Define how it is useful to people, and which people

  19. sch

    Definitely. Is there a mailing list or discussion forum where I can post about it?

  20. sch

    Are there clients that have attempted to do this or something else related to PubSub in the past?

  21. sch

    Besides Jappix, which is of Movim now.

  22. MattJ

    sch: jdev if you want to reach client developers

  23. MattJ

    Gajim had a pubsub browser

  24. sch

    I think I do not know how to use it, as I have failed to make any visual result with PubSub using Gajim.

  25. MattJ

    Sure, it's an example of the protocol-first development I was talking about 🙂

  26. MattJ

    Your example of posting attachments to a MUC is a good example of a feature, but it could be implemented in a number of ways

  27. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support *Groupchat* The feature is "pinned" posts, media and other messages, which would be conveniently possible with PubSub. Note: Unlike groupchat subject message, PubSub would provide rich media. *Chat* This feature would also be useful for people who want to share bookmarks or documents they want to distribute or share with specific people. Note: PubSub would make sharing nonintrusive, in contrast to sending a file in-chat, in the middle of the chat.

  28. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support > Your example of posting attachments to a MUC is a good example of a feature, but it could be implemented in a number of ways *Groupchat* The feature is "pinned" posts, media and other messages, which would be conveniently possible with PubSub. Note: Unlike groupchat subject message, PubSub would provide rich media. *Chat* This feature would also be useful for people who want to share bookmarks or documents they want to distribute or share with specific people. Note: PubSub would make sharing nonintrusive, in contrast to sending a file in-chat, in the middle of the chat.

  29. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support > Your example of posting attachments to a MUC is a good example of a feature, but it could be implemented in a number of ways *Groupchat* The feature is a series of "pinned" posts, media and other messages, which would be conveniently possible with PubSub. Note: Unlike groupchat subject message, PubSub would provide rich media. *Chat* This feature would also be useful for people who want to share bookmarks or documents they want to distribute or share with specific people. Note: PubSub would make sharing nonintrusive, in contrast to sending a file in-chat, in the middle of the chat.

  30. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support > Your example of posting attachments to a MUC is a good example of a feature, but it could be implemented in a number of ways *Groupchat* The feature is a series of "pinned" posts, media and other messages, which would be conveniently possible with PubSub. Note: Unlike groupchat subject message, PubSub would provide rich media. *Chat* This feature would also be useful for people who want to share bookmarks or documents they want to distribute or share with specific people. Note: PubSub would make sharing nonintrusive, both visually and functionally, in contrast to sending a file in-chat, in the middle of the chat.

  31. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support https://chat.modernxmpp.org/paste/29bdf8f4-b0c7-46b1-aa00-18d077dfee9f

  32. sch

    > So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support > Your example of posting attachments to a MUC is a good example of a feature, but it could be implemented in a number of ways *Groupchat* The feature is a series of "pinned" posts, media and other messages, which would be conveniently possible with PubSub. 1) Unlike groupchat subject message, PubSub would provide rich media. 2) Series of posts may be 3 to 100. *Chat* This feature would also be useful for people who want to share bookmarks or documents they want to distribute or share with specific people. 1) PubSub would make sharing nonintrusive, both visually and functionally, in contrast to sending a file in-chat, in the middle of the chat. 2) This would also make document sharing more efficient by linking to a PubSub node entry instead of uploading a file again and again to various of people or groupchats.

  33. sch

    I think these points, albeit can be done in other forms, are convincing.

  34. sch

    edhelas, thank you for visually enlightening us to PubSub with Movim. Without you, I would have been porbably still ignoring PubSub.

    ♥ 1
  35. Tengiz

    Selam

  36. Tengiz

    Beni duyan var mı

  37. Tengiz

    Beni duyan var mı?