Hi, thanks for the feedbacks and sorry for my delay for the answer.
My answers bellow:
Le 26/10/2022 à 17:32, Goffi a écrit :
Hi,
Le mercredi 26 octobre 2022, 16:45:10 CEST Daniel Gultsch a écrit :
However in practice Microblogging was not applicable in more common cases
and some related features were not used
Citation needed. I’m inclined to trust the author on that but I'm
generally curious on how and when mirco blogging didn’t work and what
features were not used.
I'm curious too actually, I've quickly read this new XEP, and I'm not exactly
sure about its purpose and how it differs from XEP-0277, a section explaining
clearly why a new XEP is necessary and the difference from XEP-0277 would be
more than welcome.
I might rephrase and complete the introduction section indeed.
The goal of this XEP is to take the 0277 and define it to a more generic
level. The core change is to use the pubsub#type metadata to clearly
define what is a "social feed" and what is not. Today we can't easily
differentiate that except by guessing some node configuration and if the
node contains Atom items.
This XEP introduce "profiles" that are defined in pubsub#type (see work
done in
https://xmpp.org/extensions/xep-0060.html#revision-history-v1.23.0), the
default being 'urn:xmpp:social:0'
https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_base,
the XEP-0277 now being a specific profile of Pubsub Social Feed, fully
backward compatible.
Some random comments:
- I really doesn't like this marketing name "PubSub Social Feed",
"Microblogging over XMPP" is not great either because classic blogging is
doable too, but something like "Blogging" or "Atom over XMPP" would be more
appropriate IMHO. I can live with this though
No problem changing the title for something that fits everyone
- if we're about to define a new XEP, we should get rid of the mandatory text
version when we publish XHTML (but that would make it incompatible RFC4287,
however I think it's not the best choice for XMPP use case)
I think its still valuable in some cases, especially for compatibility
with external tools that wants to import/export Atom items also I'd
prefer to not break any compatibility with Atom.
- XHTML-IM should not be recommended IMHO, we need real XHTML fir blogging and
also to be able to make proper gateways to other protocols. Security
Consideration should give precise advice on how to sanitize the content
instead.
I agree, I will remove that part from the XEP. Actually in Movim I only
use XHTML as defined in
https://www.rfc-editor.org/rfc/rfc4287#section-3.1.1.3
- I don't think that a html alternate link SHOULD be published, the protocol
should not be related to HTML, HTML rendering is just what some clients do
To me that is just linked to RFC4287, it is not mandatory and only shown
in the examples. Maybe I overlooked but it is not advised as a SHOULD.
- "pubsub#access_model" should not be set to "presence" but to "open" IMO. For
privacy reason, "presence" by default may be OK though, I'm not exactly sure
what is the best option here.
I'm ok to remove that part (we are talking about
https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_microblog_node_config)
and leave the freedom to the implementer, also I'd prefer to change
XEP-0277 to add that instead of defining it on top of it in Pubsub
Social Feed. Good point.
- what is this "Gallery profile" thing ? It looks like a terrible way to do
photo galleries, ignoring all the work done by stuff like XEP-0447. Please, I
see no good reason to have this.
The goal is not to replace or have "two-standards". This Gallery profile
is a way to ensure that the node is having at least one attached picture
to all the items, allowing clients to display it using a specific layout
(a grid for example). This would allow to have Picture based social
feeds such as Instagram etc...
In Movim I'm representing such feeds using this layout for example
https://mov.im/?node/comics.movim.eu/TheOatMeal, also having a node
configured with 'urn:xmpp:gallery:0' will allow me to present an
article/item creation form that enforces at least one picture to be
attached.
The picture can come from different sources and the client should handle
cases where it can't be retrieved (or if the specific source is not
implemented yet for example).
- style remark: quotes (notably in section 4.1) are not following XEP-0143
guidelines
Noted !
Regards
Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
The goal of this XEP is to pose the bases of "what is a social feed" in
XMPP and the core of it relies on pubsub#type (I asked the support in
ejabberd there by the way
https://github.com/processone/ejabberd/issues/3914).
The idea would be next to add a few more XEPs to define maybe other
pubsub#type from that one and to see how they can be handled
client/server side. For example we are thinking of adding pubsub#type
based filters in Pubsub services. That would allow clients to only get
the main article-nodes, comment-nodes, galleries-nodes etc... based on
their preferences and not retrieve everything and then filter client
side (it is one of the big performances issues that I have right now).
Regarding the link with XEP-0447: Stateless file sharing I don't see why
<file-sharing> can't be used with this XEP. I can try to adapt the
'urn:xmpp:gallery:0' to gives the choice of the implementer on how he
would like to attach this mandatory picture per item (having two
examples, one with a '<link rel=enclosure/>' and another one with
'<file-sharing xmlns=urn:xmpp:sfs:0>' for example :) ).
Movim has been for more than 10 years in a weird state where I was
mostly based on 0277 with "hacks" to extend it outside this scope of
Microblog. This XEP is a step ensuring that everything that is done is
fully standard and setting the bases of some future extensions in that area.
Regards,
Timothée Jaussoin aka edhelas
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
