17 Dec
2024
17 Dec
'24
7:56 a.m.
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.
17 Dec
17 Dec
10:21 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)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
10:23 a.m.
- 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.
10:55 a.m.
Le 17/12/2024 à 18:23, Stephen Paul Weber a écrit :
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&c…
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
- 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.
_______________________________________________
Standards mailing list --standards(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
10:37 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11:43 a.m.
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/29dcc9b94ccfd514cf388979e7210…).
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 :
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org 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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
18 Dec
18 Dec
2:18 a.m.
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
0
days inactive
1
days old
6 comments
4 participants
participants (4)
-
Daniel Gultsch -
Goffi -
Stephen Paul Weber -
Timothée Jaussoin