-
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.
-
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 ? ↺
-
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)
-
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.
-
sch
What do you think of this?✎ -
sch
What do you think of this idea for viewing PubSub with chat clients? ✏
-
MattJ
sch: like Movim?
-
sch
Yes, but with lesser emphasis on PubSub.
🤔 1 -
sch
Because this is namely a chat client.
- edhelas is hurt
- sch _hugs_ edhelas
- sch *hugs* edhelas
-
sch
Of course, this would indeed make chat clients to behave more like Movim.
-
MattJ
I think that's up to individual clients
-
sch
Yes, of course.
-
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.
-
MattJ
So instead of asking if clients should support pubsub, decide what the feature is that you want clients to support
-
MattJ
Define how it is useful to people, and which people
-
sch
Definitely. Is there a mailing list or discussion forum where I can post about it?
-
sch
Are there clients that have attempted to do this or something else related to PubSub in the past?
-
sch
Besides Jappix, which is of Movim now.
-
MattJ
sch: jdev if you want to reach client developers
-
MattJ
Gajim had a pubsub browser
-
sch
I think I do not know how to use it, as I have failed to make any visual result with PubSub using Gajim.
-
MattJ
Sure, it's an example of the protocol-first development I was talking about 🙂
-
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
-
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.✎ -
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. ✏
-
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. ✏
-
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. ✏
-
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 ✏
-
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.
-
sch
I think these points, albeit can be done in other forms, are convincing.
-
sch
edhelas, thank you for visually enlightening us to PubSub with Movim. Without you, I would have been porbably still ignoring PubSub.
♥ 1 -
Tengiz
Selam
-
Tengiz
Beni duyan var mı✎ -
Tengiz
Beni duyan var mı? ✏