On 28/04/2025 07.12, Schimon Jehudah wrote:
Last week, I have contacted various of projects and
asked to render
messages with XMPP URI by their particular context.
Please refer to the Gemini page or see the attached file for references.
gemini://woodpeckersnest.space/~schapps/journal/2025-04-24-rendering-xmpp-uri-by-context.gmi
The above Gemini page seems to be available via HTTP under
https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2025-0…
After communicating this information to nephele, the
developer of
Renga chat client for Haiku, he has advised to standartize this
approach by adding a new attribute to XEP-0372.
Sun 27 Apr 2025 06:03:34 PM - nephele:
The XEP 0372 as it exists now seems to almost hit
what you want, maybe
only another type is needed. for example
<reference xmlns='urn:xmpp:reference:0'
begin='72'
end='78'
type='adhoc'
uri='xmpp:nephele@xmpp.org?command'/>
XEP-0372 seems to currently specify two values for type: 'mention' and
'data'. Even though the XEP is experimental and does not clearly mention
that the value of 'type' must be one of 'mention' or 'data',
retrospectively adding more values could be considered a breaking change
that warrants a namespace bump.
One way around that would be to add a data kind information for
type='data. And when it comes to extending a XEP, or XMPP in general, an
extension element should be taken into consideration.
For example, instead of the above
<reference xmlns='urn:xmpp:reference:0'
begin='72'
end='78'
type='data'
uri='xmpp:nephele@xmpp.org?command'>
<reference-data xmlns='urn:xmpp:reference-data:0'>
<kind>
<feature>http://jabber.org/protocol/commands</feature>
</kind>
</reference-data>
</reference>
Even though this is more verbose, it has some advantages. First, it
clearly establishes an optional extension to the required attributes of
XEP-0372 in an backwards compatible way. Second, it allows to specify
the otherwise unspecified "data references" of XEP-0372, not only to be
ad-hoc specific, but to cater for the whole XMPP ecosystem by re-using
disco#info's </feature>.
I am not saying that this is how it should be done, but merely wanted to
point out this option for consideration and discussion.
- Flow