The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Gateway Relayed Encryption
Abstract:
This specification describes a mechanism for end-to-end encryption
with gateways that is compatible with third-party networks.
URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Greetings!
I am drafting a post to next Tuesday evening about Metalink.
I did a superficial search, and I did not find a mention of Metalink in
the XEP index.
Metalink is known as standard RFC 5854, and RFC 6249.
> Metalink supports listing of multiple partial and full file hashes
> along with PGP signatures. It supports listing any URI (i.e. FTP,
> Gemini, HTTP, rsync, BitTorrent, eD2k, IPFS, magnet link etc.).
It also has a "description" field, which is crucial in messaging
system, as it can save the effort of sending an extra message to
describe the content. This saves in half the number of messages upon
sharing files via messages.
See the example Metalink file in the following post.
https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-1…
In the example Metalink file, the content is available via BitTorrent,
eD2k, FTP, HTTP, and Kad.
Handling Metalink would be of benefit to XMPP.
Sending of a file:
> http://hfu.xmpp.i2p/StealThisFilm.Part1.avi
> This is the first part of the movie "Steal This Film I" from 2006.
Sending of a Metalink file:
> http://hfu.xmpp.i2p/StealThisFilm.Part1.metalink
XMPP client parses the Metalink file (StealThisFilm.Part1.metalink),
and displays the given description which is found in that file.
I advise to create an XEP for handling of Metalinks.
I would be greateful to whom who would want to intstruct me.
Kind regards,
Schimon
Version 1.0.0 of XEP-0421 (Occupant identifiers for semi-anonymous
MUCs) has been released.
Abstract:
This specification defines a method that allows clients to identify a
MUC participant across reconnects and renames. It thus prevents
impersonification of semi-anonymous users.
Changelog:
Accept as Stable as per Council Vote from 2025-01-14. (XEP Editor
(dg))
URL: https://xmpp.org/extensions/xep-0421.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: GRE Encrypter: OpenPGP
Abstract:
This GRE Encrypter uses OpenPGP to encrypt payload.
URL: https://xmpp.org/extensions/inbox/gre-encrypter-openpgp.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: GRE Formatter: MIME
Abstract:
This GRE Formatter uses Multipurpose Internet Mail Extensions (MIME)
to format payload.
URL: https://xmpp.org/extensions/inbox/gre-formatter-mime.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
[[Zombie Thread!!]
On Sat, 24 Aug 2019 at 17:51, Jonas Schäfer <jonas(a)wielicki.name> wrote:
> On Mittwoch, 21. August 2019 01:06:07 CEST Dave Cridland wrote:
> > On Tue, 20 Aug 2019 at 16:58, Jonas Schäfer <jonas(a)wielicki.name> wrote:
> > > On Dienstag, 20. August 2019 10:34:22 CEST Dave Cridland wrote:
> > > > > *PR #808 - XEP-0045: Add Tags configuration and metadata* -
> > > > > https://github.com/xsf/xeps/pull/808
> > > > > Dave: [pending]
> > > > > Georg: [on-list]
> > > > > Jonas: +1
> > > > > Kev: [pending]
> > > > > Link: [on-list]
> > > >
> > > > I think I'm -1 on this. I don't think that having tags is a bad
> idea, in
> > > > and of itself, but I'm concerned with adding more stuff to XEP-0045.
> > > >
Note that I didn't say "adding more stuff to MUC". Fine with adding more
stuff to MUC, but XEP-0045 ought to be Final by now, and adding yet more
functionality to XEP-0045 isn't going to help that. I'm not sure this
change really satisfies the spirit of Stable either.
On top of that, re-reading the proposal, yes - it's just too simplistic. So
even if we did put it in XEP-0045 (or rather, ram it on the side with some
glue, string, and sticky-backed plastic for speed) I think it'd eventually
end up with more development and that would again affect the status of
XEP-0045.
>
> > > > In general, I think that tagging in this "dumb" way is probably never
> > >
> > > going
> > >
> > > > to be enough, and a more considered approach might be better.
> > > >
> > > > For what it's worth, I'm open to having my mind changed on this.
> > >
> > > As someone in favour of this, what do you consider "dumb" about this?
> >
> > Dumb as in the tags are simply "there", and therefore only of use to an
> > external search engine, really.
> >
> > So things you can't do are filter by tag on a disco#items search, say, or
> > assign some internal meaning to specific tags for state management or
> > workflow or something.
> >
> > Put another way, I'm not sure this gives anything to build upon - it's
> just
> > a field of strings, and there's no indication of semantics or intended
> use
> > here. I can implement it easily enough from the spec, but I have no idea
> > how to use it beyond "put some strings here".
> >
> > Quite a lot of '45 is like this already, and I'd rather not make things
> > worse.
>
> Fair enough. Do you have a proposal with which we could provide a similar
> UX
> to users?
>
Yeah, sorry, I didn't reply to this. Well, better (5 years) late than never!
Put the tagging in a different specification, and either make a registry
for the tag names, or make the tags URIs (or namespaced by URIs) so they
can be more safely permissionless. Pubsub nodes could probably be taggable
too, via possibly the same mechanism.
Once you've done this, then adding search-by-tag seems possible (and even
sensible), and we can add additional semantics to particular tags safely.
The most obvious thing to do would be to add a XEP-0128 form which just
holds tags, make the tags URIs, and make a URI prefix that means "these are
plaintext human-readable tags" - but you could of course do the tag prefix
URI within the field name instead.
Dave.
>
> kind regards,
> Jonas_______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe(a)xmpp.org
> _______________________________________________
>
Le mercredi 8 janvier 2025 20:07:04 heure normale d’Europe centrale, vous avez écrit :
> On 1/8/25 9:49 AM, Peter Saint-Andre wrote:
> > On 1/8/25 9:43 AM, Peter Saint-Andre wrote:
> >> On 1/8/25 4:08 AM, Goffi wrote:
> >>> Hello,
> >>>
> >>> I'm very interested in XEP-0284, and there is this PR from Link Mauve
> >>> buried for years to revive it:
> >>> https://github.com/xsf/xeps/pull/904
> >>>
> >>> I would like to put that on council agenda, but I have the following
> >>> question:
> >>>
> >>> - are the previous author still unreachable? I'll put their address
> >>> as recipients of this email.
> >>
> >> I am connected to Tom on LinkedIn and Joonas is there too but I'm not
> >> connected to him. If it's important, I can track them down.
> >
> > P.S. I have forwarded this note to a non-bouncing email address for Joonas.
>
> I heard back from Joonas and he is reachable but doesn't have the time
> to contribute and doesn't feel that he needs to be consulted. However,
> he's excited that people are still working on SXE. :-)
>
> Peter
Great, thanks Peter!
This email was sent only to me, I believe by mistake, I'm replying to standard@ as I think that it is valuable information for the Council,
OK, Link Mauve is currently unresponsive, let's wait and see if he's still interested in taking over (otherwise, I can take care of it, but I hope that Link Mauve is still willing to push it to stable).
Best,
Goffi
Version 0.3.0 of XEP-0421 (Occupant identifiers for semi-anonymous
MUCs) has been released.
Abstract:
This specification defines a method that allows clients to identify a
MUC participant across reconnects and renames. It thus prevents
impersonification of semi-anonymous users.
Changelog:
* Adjust wording to use semi-anonymous or pseudonymous instead of
anonymous
* Explicitly mention issues arising from occupant id matching across
rooms
* Add example with server secret instead of room secret
* Add some pseudocode (lmw)
URL: https://xmpp.org/extensions/xep-0421.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Hello,
I'm very interested in XEP-0284, and there is this PR from Link Mauve buried for years to revive it:
https://github.com/xsf/xeps/pull/904
I would like to put that on council agenda, but I have the following question:
- are the previous author still unreachable? I'll put their address as recipients of this email.
- Peter Saint-Andre is still around as the XSF Treasurer. So Peter could you tell us if you agree with this PR and with Link Mauve taking over the XEP?
- Link Mauve, are you still OK with this PR and being an author of this specification?
If all 3 above give green lights, Daniel would you mind adding this to Coucil agenda?
Thank you all!
Best,
Goffi
