Proposed XMPP Extension: Pubsub Stories
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Stories Abstract: This specification defines a way of publishing Stories over XMPP. URL: https://xmpp.org/extensions/inbox/stories.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Le mardi 17 décembre 2024, 15:56:42 heure normale d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Stories Abstract: This specification defines a way of publishing Stories over XMPP.
URL: https://xmpp.org/extensions/inbox/stories.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Edhelas, Thank you for your contribution. I've voted +0 on this one, so I'm not blocking it but I'm not pushing either. I want to explain why here. I think this feature is popular and thus likely useful and desirable. However, I have some issues with the design of this specification: - It's not generic; it's only for blogging. Retracting items after a delay should be a generic feature. - The delay is vague and should be specified. Ideally, it should be possible to customize the delay, with a reasonable value set by default. - The retraction is done by the client, which is my major concern: if the client doesn't connect (or connects much later), items won't be retracted. The retraction should be handled by the Pubsub service. While I appreciate the stories profile, I believe the retraction design isn't quite right. I suggest that we completely remove this retraction feature from this specification and move it to a new one. This new spec should use a well-known node configuration to remove items after a customizable amount of time (or at a specific date and time). We can add a fallback asking the publishing client to retract items if the service doesn't support this config option. This way, we have a clean and generic method for item retraction. What are your thoughts? Best, Goffi
- It's not generic; it's only for blogging. Retracting items after a delay should be a generic feature.
I think it's only for media, blogging isn't allowed. Though I agree with what was said in council that multiple media should be allowed to do "slideshow" style stories.
- The delay is vague and should be specified. Ideally, it should be possible to customize the delay, with a reasonable value set by default. - The retraction is done by the client, which is my major concern: if the client doesn't connect (or connects much later), items won't be retracted. The retraction should be handled by the Pubsub service.
I think all mention of retraction could be removed. It's not the point of the XEP and I think it distracts from the purpose. If clients want to hide after eg 24 hours that's up to them and their UX desires.
Le 17/12/2024 à 18:23, Stephen Paul Weber a écrit :
- It's not generic; it's only for blogging. Retracting items after a delay should be a generic feature.
I think it's only for media, blogging isn't allowed.
Though I agree with what was said in council that multiple media should be allowed to do "slideshow" style stories.
Yes the Stories XEP enforce one media per item, but automatic retractation as a generic Pubsub node configuration could be useful on a more global level. Once we have pubsub#expire I think the Stories XEP will mention it as a SHOULD, leaving the freedom of the developer, and user, to define it or note. It could also be used for other PEP nodes, for example User Location or User Tune. However I'm opposed by the idea of multiple medias, how the Stories are handled in all the implementations I know (Instagram, Snapchat, Telegram, Signal) is that each Story has one media attached and the client is actually taking care of "grouping" all the recent Stories of one user as a slideshow. All the implementations above have the following behavior: tap right to go to the next story of the user or the next user story if there's none left, swipe right to directly jump to the next user. In the Telegram API for example: https://core.telegram.org/api/stories : |media|: The story media (a vertical photo or a vertical video, max 30 MB). Handling multiple medias per Story AND multiple Stories at the same time will be very confusing in the UI. If you want to have several images in your Story a few of those implementations allow you to craft a unique image with a "collage" of several images (they are called Layout on Instagram). This is something that I might consider to do on my side. Combine multiple photos into one on your Instagram story https://help.instagram.com/385953178139846/?helpref=platform_switcher&cms_pl... I hope that you'll understand my feedback, I'd like to keep things very simple but this limitation is really the bare minimum to have a coherent flow and implementation in the clients. Regards, edhelas
- The delay is vague and should be specified. Ideally, it should be possible to customize the delay, with a reasonable value set by default. - The retraction is done by the client, which is my major concern: if the client doesn't connect (or connects much later), items won't be retracted. The retraction should be handled by the Pubsub service.
I think all mention of retraction could be removed. It's not the point of the XEP and I think it distracts from the purpose. If clients want to hide after eg 24 hours that's up to them and their UX desires.
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
Hi ! I'm ok to move the retractation thing in a specific XEP, indeed it would take a bit more effort to have it as a server feature and I didn't wanted to block the whole process. Once something like a pubsub#expire node configuration exist we could upgrade again the Stories XEP to rely on it. For now the current Stories XEP will define a new kind of node where "Stories like" content will be there, allowing the clients to configure their UX/UI properly. Regards, edhelas Le 17/12/2024 à 18:21, Goffi a écrit :
Le mardi 17 décembre 2024, 15:56:42 heure normale d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Stories Abstract: This specification defines a way of publishing Stories over XMPP.
URL: https://xmpp.org/extensions/inbox/stories.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Edhelas,
Thank you for your contribution.
I've voted +0 on this one, so I'm not blocking it but I'm not pushing either. I want to explain why here.
I think this feature is popular and thus likely useful and desirable. However, I have some issues with the design of this specification:
- It's not generic; it's only for blogging. Retracting items after a delay should be a generic feature. - The delay is vague and should be specified. Ideally, it should be possible to customize the delay, with a reasonable value set by default. - The retraction is done by the client, which is my major concern: if the client doesn't connect (or connects much later), items won't be retracted. The retraction should be handled by the Pubsub service.
While I appreciate the stories profile, I believe the retraction design isn't quite right.
I suggest that we completely remove this retraction feature from this specification and move it to a new one. This new spec should use a well-known node configuration to remove items after a customizable amount of time (or at a specific date and time). We can add a fallback asking the publishing client to retract items if the service doesn't support this config option. This way, we have a clean and generic method for item retraction.
What are your thoughts?
Best, Goffi
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi again, Holger Weiß just told me that there is already a pubsub#item_expire feature in 0060 and that it is implemented in ejabberd already (https://github.com/processone/ejabberd/commit/29dcc9b94ccfd514cf388979e7210d...). I completely overlooked that. So I propose that I update my proposal with another PR that will mention this as a SHOULD in the Stories node configuration and update my implementation to rely on that. Regards, edhelas Le 17/12/2024 à 18:37, Timothée Jaussoin a écrit :
Hi !
I'm ok to move the retractation thing in a specific XEP, indeed it would take a bit more effort to have it as a server feature and I didn't wanted to block the whole process.
Once something like a pubsub#expire node configuration exist we could upgrade again the Stories XEP to rely on it.
For now the current Stories XEP will define a new kind of node where "Stories like" content will be there, allowing the clients to configure their UX/UI properly.
Regards,
edhelas
Le 17/12/2024 à 18:21, Goffi a écrit :
Le mardi 17 décembre 2024, 15:56:42 heure normale d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Stories Abstract: This specification defines a way of publishing Stories over XMPP.
URL: https://xmpp.org/extensions/inbox/stories.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Edhelas,
Thank you for your contribution.
I've voted +0 on this one, so I'm not blocking it but I'm not pushing either. I want to explain why here.
I think this feature is popular and thus likely useful and desirable. However, I have some issues with the design of this specification:
- It's not generic; it's only for blogging. Retracting items after a delay should be a generic feature. - The delay is vague and should be specified. Ideally, it should be possible to customize the delay, with a reasonable value set by default. - The retraction is done by the client, which is my major concern: if the client doesn't connect (or connects much later), items won't be retracted. The retraction should be handled by the Pubsub service.
While I appreciate the stories profile, I believe the retraction design isn't quite right.
I suggest that we completely remove this retraction feature from this specification and move it to a new one. This new spec should use a well-known node configuration to remove items after a customizable amount of time (or at a specific date and time). We can add a fallback asking the publishing client to retract items if the service doesn't support this config option. This way, we have a clean and generic method for item retraction.
What are your thoughts?
Best, Goffi
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Le mardi 17 décembre 2024, 19:43:37 heure normale d’Europe centrale Timothée Jaussoin a écrit :
Hi again,
Holger Weiß just told me that there is already a pubsub#item_expire feature in 0060 and that it is implemented in ejabberd already (https://github.com/processone/ejabberd/commit/ 29dcc9b94ccfd514cf388979e7210d01cb97d5f4).
I completely overlooked that. So I propose that I update my proposal with another PR that will mention this as a SHOULD in the Stories node configuration and update my implementation to rely on that.
Regards,
edhelas
Hi, Great, thank you for considering my feedback. I too overlooked `pubsub#item_expire`, it's exactly what we need, and you can retain the fallback in your XEP (i.e., retraction done by publishing client) if the option is not supported by the pubsub service. With that, my concerns are addressed, and I'm changing my vote from +0 to +1. Best, Goffi
participants (4)
-
Daniel Gultsch -
Goffi -
Stephen Paul Weber -
Timothée Jaussoin