> special meaning defined herein if the corresponding "form"-type form had the
> field "hidden"' - but won't block based on that.
>
> Jonas: +1
> Zash: [on-list]
> Daniel: [on-list]
> Georg: +1 (though not sure it addresses Dave's remark abou
Am Di., 12. Mai 2020 um 19:04 Uhr schrieb Tedd Sterr :
>
> https://logs.xmpp.org/council/2020-05-06?p=h#2020-05-06-203d250e68ba702f
>
> 1) Roll Call
> Present: Jonas, Zash, Daniel, Georg
> Apologies: Dave
>
> 2) Agenda Bashing
> Nothing to add/modify.
>
> 3)
#x27; is SCRAM specific, because its specification then surely
> would declare the supported SASL mechanisms.
This syntax sounds very reasonable to me.
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
+1 for a full migration to Gitlab. No mirroring to Github. No
nonsense. Anything that will help our editors.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
__
say anything on whether either or both value and name can be omitted.
Can someone more familiar with what this actually maps to clarify?
Note that the implementations sending this are parsing this from firefoxes SDP.
cheers
Daniel
___
Standards mailing l
There is a 2011 thread on the same topic:
https://mail.jabber.org/pipermail/jingle/2011-March/001438.html that
as far as I can tell (my personal archives don’t go back that far)
never went anywhere.
Am Mi., 17. Juni 2020 um 14:17 Uhr schrieb Daniel Gultsch :
>
> Hi,
>
> I've
> 4b) PR #598 (XEP-0050: Try to clarify usage of 'execute') -
> https://github.com/xsf/xeps/pull/598
> Jonas, superpowered editor extraordinaire, added wording to the PR,
> specifically, a note discouraging use of the execute action
> Dave thinks this is deep into 'least harm' territory, and will
Am Di., 16. Juni 2020 um 16:44 Uhr schrieb XEP Editor Pipeline
:
> XEP-0338.
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Yes
>
>
1.2 this is probably tls-unique and for TLS1.3 this is
tls-exporter. If you can’t make sure that you support that, don’t
implement it.
(Which is probably something the XEP should be explicit about in case
we come to a consensus here.)
cheers
Daniel
___
Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus :
> If you send 'y', which implies that you, the client, did not select a
> -PLUS mechanism for authentication, while the server announces at least
> one SCRAM-*-PLUS mechanism, then the server may suspect a MitM attack
> and terminates th
Am Fr., 31. Juli 2020 um 21:43 Uhr schrieb Tedd Sterr :
> 1) Roll Call
> Present: Georg, Jonas, Zash, Dave
> Absent: Daniel
Sorry. I fell asleep before our meeting. Time is still weird.
> 3) Editor's Update
> Congratulations to MattJ for getting version 0.7.0 of XEP-0313
s means the publish option doesn’t need to be
registered. Just the node configuration field.
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Am Sa., 8. Aug. 2020 um 07:13 Uhr schrieb Daniel Gultsch :
>
> Am Sa., 8. Aug. 2020 um 07:07 Uhr schrieb Ruslan N. Marchenko
> :
> >
> > Hi Standards,
> >
> > I'm trying to extend PEP server implementation to support OMEMO and
> > stumbled upon fol
n a not too distant future in favor of
Bookmarks 2.0
Otherwise I'd probably retract this as this author.
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
m OK with being overruled by someone who prefers to stick it
into 0122.
cheers
Daniel
Am Mi., 16. Sept. 2020 um 22:51 Uhr schrieb Maxime Buquet :
>
> Hi Standards,
>
>
> A year ago during a sprint we worked on implementing bookmarks2 and
> submitted a few changes to the spec at
down anyway please consider using a standardized
syntax"
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
happily accept messages with an
x-oob URL and *no* body. What it (currently) won’t accept is 'mixed'
content with body != x-oob.
As far as discovery is concerned there is not just "the MUC issue" but
also offline clients and
Am Mi., 11. Nov. 2020 um 02:46 Uhr schrieb Tedd Sterr :
>
> https://logs.xmpp.org/council/2020-11-04?p=h#2020-11-04-51d2be3786d1879f
>
> 1) Roll Call
> Present: Jonas, Dave, Daniel, Zash, Georg
>
> 2) Agenda Bashing
> Georg wanted to add his XEP-0401 (Easy User Onboa
> 4b) PR #1001 (XEP-0393: clarify rules for span directives) -
> https://github.com/xsf/xeps/pull/1001
> See [2] for relevant war of semantics and pedantry discussion.
> Daniel: [on-list]
+1
___
Standards mailing list
Info: https://mai
t; Jonas checks whether Link Mauve has the IPR agreement from Daniel to resubmit
> his work under a different track…
> Daniel vaguely remembers his offer to move this to a different track was
> rejected, so accepting now would be overruling a previous Council decision.
> Jonas rummages th
-truly-distributed/
Regards,
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
> 4) Proposed XMPP Extension: Service Outage Status -
> https://xmpp.org/extensions/inbox/service-outage-status.html
> Georg: +1
> Jonas: +1 (will send a few notes to the list [1])
> Daniel: [on-list]
> Dave: [on-list]
>
only use
those and soon the implicit ones have to be set up be server. (Like
try running an XMPP not on domain:5222 and connections will fail)
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
On 31/01/2021 12:08, Daniel Pocock wrote:
>
> Hi all,
>
> Is there any ongoing work in true P2P, serverless XMPP similar to P2P-SIP
>
> https://en.wikipedia.org/wiki/Peer-to-peer_SIP
>
>
> or the Jami application:
>
> https://jami.net/
>
>
&g
ersally true.
It depends on the requirements of each user
A user's requirements may change over time, they might not see it coming
either.
Imagine a poster promoting this concept. A big headline, "SERVERLESS"
and a picture of the former US president.
Regards,
Daniel
__
On 07/02/2021 14:24, Andrew Nenakhov wrote:
> вс, 7 февр. 2021 г. в 12:45, Daniel Pocock :
>
>> Imagine a poster promoting this concept. A big headline, "SERVERLESS"
>> and a picture of the former US president.
>
> Former US president just needs his own serve
oesn’t have to worry about it.)
Just thought it was interesting that these things keep popping up. As
much as we love XMPP and XML there is apparently a demand for
something "simpler".
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
should not infer a general rule from this some additions
might make a namespace bump necessary.
(Alternatively a new, optional element, can be moved into it's own namespace.)
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.o
somehow got under the impression that earlier versions of the MAM XEP
already did that but failed to find anything in the XEP archive about that.
If that has been the case is there a reason that feature has been removed?
cheers
Daniel
plicate messages I'm seeing.
Right now I'm trying to fake dedup by matching the body and the message id
but that of course fails when my contacts clients don't set a message id.
cheers
Daniel
2015-01-22 1:53 GMT+01:00 Holger Weiß :
> * Daniel Gultsch [2015-01-22 01:11]:
> > right now a client when querying the MAM archive has to relay upon the
> fact
> > that server time and client time are the same (which they never are) or
> > that all received messages
to one and a carbon of it to the
> other (and how the priority/routing is supposed to be handled in that
> case).
>
Defenitly not both like it is done currently. (Or has been done?)
cheers
Daniel
2015-05-06 16:12 GMT+02:00 Holger Weiß :
> * Daniel Gultsch [2015-05-05 17:13]:
> > 2015-05-05 16:30 GMT+02:00 Georg Lukas :
> > > One possible workaround would be to mark all MUC PMs, like it is done
> by
> > > prosody: http://hg.prosody.im/trunk/rev/09151d26560a
.
And I'm currently not really seeing the point of a client adding an id
since the client can already set the stanza id. With an the by attribute we
don't have to decide on whether or not there is a use case for the
client-id.
cheers
Daniel
2015-06-05 13:01 GMT+02:00 Daniel Gultsch :
>
> And I'm currently not really seeing the point of a client adding an id
> since the client can already set the stanza id. With an the by attribute we
> don't have to decide on whether or not there is a use case for the
> c
server (current XEP says
optionally)
cheers
Daniel
P.S.: I don't have a strong opinion on the MAM id generation schema (And
this doesn't belong to the message-id-discussion but should be in a
separate MAM discussion since it has nothing to do with the actual
message-id XEP besides the
Great idea. And I cant imagine a client breaking because of an additional
attribute. A version bump for this tiny (but very useful feature) will do
more harm than good.
- Daniel
failed due to a SM time out.
cheers
Daniel
out of curiosity does this mean you are working on implementing jingle file
transfer 0.16 in gajim?
2015-06-20 14:08 GMT+02:00 Yann Leboulanger :
> Hi all,
>
> I just read the version 0.16 of Jingle File Transfer XEP, and saw that
> you removed the flow.
> Just to mention that it is used in Gaji
owledge - are the only clients
supporting Jingle FT)
cheers
Daniel
gt; non-anonymous in MUC2, to solve some of the addressing messes we’ve found
> ourselves in.
>
Yes. Plus that gives us the ability to not have private messages which are
always a mess (carbons) - not sure if this is what you meant by addressing
messes.
And we can do proper PEP for avatars and other stuff.
cheers
Daniel
https://github.com/siacs/HttpUploadComponent is
a sample python implementation of such a component.
And here is a branch for Conversations that can talk to that component.
https://github.com/siacs/Conversations/tree/feature/http_upload
cheers
Daniel
ould be up to
the user (client) to decide whether to use OBB or just sending the plain
URL as text. Just providing the user with a possiblity to upload files and
get a public HTTP address for them will also allow the usage in something
like PEP avatars (they can contain HTTP URLs as source)
cheers
Daniel
we provide those people
with a very small XEP that is easily implemented and can serve as a
temporary solution until the perfect solution is ready.
- Daniel
encryption.
cheers
Daniel
2015-07-27 14:25 GMT+02:00 Kim Alvefur :
> mån jul 27 00:33:40 2015 GMT+0200 skrev Sam Whited:
> > Thoughts?
>
> Sounds good.
>
> --
> Zash
hat library developer are also lazy...
Don't get me wrong. There is definitely a place for Jingle and Jingle FT. I
don't want to deprecate Jingle at all. But Jingle is not always the right
tool for the job.
cheers
Daniel
(And once you got a proper jingle stack
for voice. doing jingle ft is not a big step)
One thing that would benefit Jingle FT much more than 'preventing' this XEP
from getting accepted is to finally deprecate SI file transfer. (See the
parallel thread started by Sam)
cheers
Daniel
eral / easier approach to send the real jid if the muc was non-anonymous
back then and still is. (That prevents admins from discovering the real jid
retrospectively but thats something we will have to live with I guess)
As for namespaces I would probably reuse XEP-0033: Advanced stanza
addressin
2015-07-31 18:31 GMT+02:00 Daniel Gultsch :
> As for namespaces I would probably reuse XEP-0033: Advanced stanza
> addressing http://xmpp.org/extensions/xep-0033.html
>
oh ok forget about this part. It doesn't have a from type
st to previously discussed rules for MAM storage (save everything
type="chat" and everything type="normal" with a body) this probably would
not spam the archive as only new clients that actually speak MAM/OMEMO
willl add that hint.
cheers
Daniel
position) but
it works with Carbons and I don't see a reason why this should not be used
for this.
Oh and please let us not discuss about the general usefulness of such read
markers. I know some people hate them.
cheers
Daniel
2015-08-27 10:26 GMT+02:00 Simon Tennant :
> In yesterday'
well instance tags only help the receiving client to discard garbage. if
you send your messages to a full jid you avoid unnecessary traffic.
On Sep 9, 2015 16:16, "Sam Whited" wrote:
> Thanks Thijs, I was forgetting about instance tags entirely. Will fix.
>
> —Sam
>
> On Wed, Sep 9, 2015 at 6:20
and more importantly makes the behavior (who will actually receive the
message) much more predictable
On Sep 9, 2015 20:32, "Daniel Gultsch" wrote:
> well instance tags only help the receiving client to discard garbage. if
> you send your messages to a full jid you avoid unn
ded inband anyway.
(right in the message stanza (you have to keep them smaller than lets say
5KiB but for thumbnails thats probably manageable)
cheers
Daniel
2015-09-03 13:11 GMT+02:00 Evgeny Khramtsov :
> Thu, 27 Aug 2015 16:10:18 + (UTC)
> XMPP Extensions Editor wrote:
>
> > V
d a little bit of time working for them every day training their
spam filter:
http://danielpocock.com/unpaid-work-training-googles-spam-filters
Regards,
Daniel
On 21/11/15 07:02, Arc Riley wrote:
> I'm on email, it did not go to spam.
Can anybody else comment on whether they got it or not?
Does anybody who did or did not receive it see any headers indicating
how Google's spam filters are classifying the message?
I'm hearing far too many reports of thes
Reminder: speaker's deadline this Friday, 27 November at 23:59 UTC
We have already received several really exciting talk proposals
but there is still time for people to propose talks or encourage
friends or colleagues to speak.
Many other dev-rooms also have a deadline in the next few days and i
FOSDEM,
> so that's 28 and 29 January. Please sign up as soon as possible on the
> dedicated wiki page, so we know who's attending:
>
> http://wiki.xmpp.org/web/Summit_19
>
> As mentioned before, we do have a Realtime Developers Room at FOSDEM, as
> a joint effort
injected that tag and a general rule to remove all
elements that have the attribute by with my entity - or something.
cheers
Daniel
2016-01-20 18:27 GMT+01:00 XMPP Extensions Editor :
> Version 0.5 of XEP-0313 (Message Archive Management) has been released.
>
> Abstract: This document defin
using an un-namespaced from or by attribute can lead to
some weird consequences.
What ever we agree on we should come up with a solution rather sooner than
later. Because having the server inject information like the original
sender in this case or stanza-ids in another is certain
here as well.
For people how haven't been at the summit this reference xep will probably
look a bit like how twitter is referencing links or images in their api. I
don't have a link right now but maybe someone else can provide this.
Cheers
Daniel
_
I created a PR for this.
People are running into issues with duplicate messages from time to time.
(Client resends them because it never got the ACK.)
2015-06-08 18:10 GMT+02:00 Sam Whited :
> On Mon, Jun 8, 2015 at 2:02 AM, Daniel Gultsch wrote:
> > Great idea. And I cant imagine
cation attribute.
cheers
Daniel
2016-02-14 21:29 GMT+01:00 Florian Schmaus :
> On 13.02.2016 12:31, Jonas Wielicki wrote:
> > On 12.02.2016 11:08, Florian Schmaus wrote:
> >> Here is my suggestion how such a XEP could look like:
> >
> >> http://geekplace.eu/xeps/xep-q
link
sharing is already seeing wide adoption (Conversations, gajim, monal,
xabber))
cheers
Daniel
2016-02-05 16:52 GMT+01:00 XMPP Extensions Editor :
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: References
>
> Abstract: This document defines XMP
the server
implementation (when MAM and offline are fed by the same data source)
for (a) it is no required to keep the session open for much longer than
regular. (ejabberd currently does this so i'm saying this here)
cheers
Daniel
___
Standards mailing
The remote-tok thing doesn't work because at this point it is already too
late as the server (read a potential MiM attacker) already receiced the
token. I think the server needs to be authenticated before the clients
sends the tok. Or am I misunderstanding the problem? Maybe the client could
at the
Hi,
2016-02-14 22:33 GMT+01:00 Daniel Gultsch :
> I would like to see this XEP support more or less arbitrary attributes
> like content-type, content-length as well as resolution (x,y) for images
> and videos as well as runtime for audio that can be used when referencing
> files o
Hi,
2016-02-24 13:35 GMT+01:00 Kevin Smith :
> On 24 Feb 2016, at 11:57, Daniel Gultsch wrote:
> > 2016-02-14 22:33 GMT+01:00 Daniel Gultsch :
> > I would like to see this XEP support more or less arbitrary attributes
> like content-type, content-length as well as resolutio
tion, thumbnail,
content-length and so forth?) Or would you rather not have attributes like
this in this XEP at all?
Cheers
Daniel
[1] http://ogp.me/
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: sta
On Wed, Jul 21, 2021 at 3:31 PM Jonas Schäfer wrote:
> 4) Items for Voting
>
> 4a) Proposed XMPP Extension: Pubsub Caching Hints
> URL: https://xmpp.org/extensions/inbox/pubsub-caching-hints.html
> Abstract: This specification provides a way to get caching information from a
> Pubsub node
+1
___
- XEP-0455: Service Outage Status
+1 to include in future section.
> - for E2EE: XEP-0450: Automatic Trust Management (ATM)
I don’t think we have enough experience with this XEP to tell whether
or not this is even a good idea.
cheers
Daniel
s own or a
response to an ICE restart we initiated.
Or to put it into WebRTC terminology how do I know if a transport-info
with changed ufrag/pwd is an Offer or an Answer.
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/lis
https://github.com/xsf/xeps/pull/1129)
b) XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126)
5) Pending Votes
(None so far)
6) Date of Next
7) AOB
8) Close
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabbe
Hi,
the next XMPP Council Meeting will take place on December 15th 2021 at
16:00Z in xmpp:coun...@muc.xmpp.org?join
The agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editor’s Update
- None. But keep an eye on the last calls that are due 2022-01-04
4) Items for Voting
- Nothing new t
Hi,
the next XMPP Council meeting will take place on January 5th 2022 at
16:00Z in xmpp:coun...@muc.xmpp.org?join
The agenda is as follows:
1) Roll call
2) Agenda bashing
3) Editors update
- None.
4) Items for voting
* LAST CALL: XEP-0424 (Message Retraction)
* LAST CALL: XEP-0425 (Message M
Hi,
the next XMPP Council Meeting will take place on January 12th 2022 at
16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
a) An Update to XEP-0353 (Jingle Message Initiation) has been
released. (https://xmpp.org/extensions
Hi,
the next XMPP Council Meeting will take place on January 12th 2022 at
16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
4) Items for voting
a) XEP-0060: Specify pubsub#type to reflect semantic info
(https://github.com/x
uests even if there is no
presence subscription)
cheers
Daniel
On Fri, Jan 7, 2022 at 12:30 PM Goffi wrote:
> in the context of my work on ActivityPub <=> XMPP gateway, I need to know if
> a PEP service handles RSM.
>
>
> Normally this is done by doing a disco#info request a
nce Suites 2021)
4) Items for voting
a) XEP-0060: Release version 1.23.0
https://github.com/xsf/xeps/pull/1152
b) XEP-0004: Release version 2.13.0
https://github.com/xsf/xeps/pull/1153
c) XEP-0060: Release version 1.23.1
https://github.com/xsf/xeps/pull/1154
5) Pending votes
Daniel on https://
nce.
The PR in question: https://github.com/xsf/xeps/pull/1153/files
Any feedback is appreciated.
cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
undermines the rights of members in such a case and therefore it could
be seen as a hack against the organization.
Regards,
Daniel
--
Debian Developer
https://danielpocock.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
On 04/02/2022 13:00, Ralph Meijer wrote:
>
> On 04/02/2022 11.39, Daniel Pocock wrote:
>>
>> [..]
>>
>> I don't understand why the CoC is being subject to a standards process.
>> It is a social phenomena. In many organizations this type of thing is
>
ecent years
since the Code of Conduct was enacted"
Debian refuses to discuss the research, they prefer to attack the
person. In other words, the CoC completely contradicts itself.
Regards,
Daniel
--
Debian Developer
https://danielpocock.com
___
Standa
On 04/02/2022 19:15, Daniel Pocock wrote:
>
> I'm putting this in a separate thread because it doesn't relate to the
> specific text that is currently proposed. Feel free to use this thread
> for any links to evidence or research for or against having a CoC.
Thanks
Hi,
the next XMPP Council Meeting will take place on February 9th 2022 at
16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
a) Published Update XEP-0060 that passed Council last week
b) Proposed XMPP Extension: PubSub Type F
Hi,
the next XMPP Council Meeting will take place on February 16th 2022 at
16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
a) The changes to 0004 and 0060 that council has voted on last week
have been published
b) Proposed
://github.com/xsf/xeps/pull/1168
5) Pending votes
a) Everyone on XEP-0045 Remove more mentions of GC 1.0
b) Daniel on obsoleting three XEPs
c) Jonas on obsoleting XEP-0038
d) Georg and Jonas on the new proto XEP (MUC Affiliations Versioning)
See Spreadsheet of Doom:
https://docs.google.com/spreadsheets
warnings
- Obsolete and update Security Considerations for XEP-0138 and XEP-0229
See Spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing
6) Date of Next
7) AOB
Daniel: +1w wfm
8) Close
titute was not. The
conclusion is a damning indictment on the CoC-culture
On 04/02/2022 18:15, Daniel Pocock wrote:
>
> I'm putting this in a separate thread because it doesn't relate to the
> specific text that is currently proposed. Feel free to use this thread
> fo
Hi,
the next XMPP Council Meeting will take place on March 16 2022 at
16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
none this week
4) Items for voting
a) XEP-0406: fix xmlns in example
https://github.com/xsf/xeps/pull/
I put together this open letter on the topic, it itemizes many of the
points in CoCs and may be useful for measuring the proposed XSF CoC:
https://danielpocock.com/open-letter-acm-codes-of-ethics-conduct/
On 04/02/2022 11:39, Daniel Pocock wrote:
>
>
> On 04/02/2022 10:40, JC Br
Hi,
the next XMPP Council Meeting will take place on March 23 2022
(today!) at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
none this week
4) Items for voting
none this week
5) Pending votes
none this week
See Spre
Hi,
the next XMPP Council Meeting will take place on March 30 2022
(today!) at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join
Notice that is an hour earlier (in UTC) than last week!
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
none this week
4) Items for voting
n
Hi,
the next XMPP Council Meeting will take place on April 13 2022 at
15:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
- Proposed XMPP Extension: Pubsub Public Subscriptions
(https://xmpp.org/extensions/inbox/pubsub-public-
Hi,
the next XMPP Council Meeting will take place on April 27 2022 at
15:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
- Proposed XMPP Extension: Ephemeral Messages
(https://xmpp.org/extensions/inbox/ephemeral-messages-v2.h
Hi,
the next XMPP Council Meeting will take place on May 18 2022 at 15:00
UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
a) NEW: XEP-0466 (Ephemeral Messages)
https://xmpp.org/extensions/xep-0466.html
b) NEW: XEP-0465 (Pubsub
Hi,
the next XMPP Council Meeting will take place on May 25 2022 at 15:00
UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
none this week
4) Items for voting
none this week
5) Pending votes
none this week
See Spreadsheet of
Hi Council members,
I’m on vacation this week and next but Jonas has kindly offered to
chair the upcoming meeting.
The next XMPP Council Meeting will take place on June 1 2022 at 15:00
UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors up
/extensions/inbox/xmpp-over-quic.html)
5) Pending votes
Daniel is pending on 'Start Last Call on XEP-0215'
See Spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing
6) Date of Next
7) AOB
Hi Council members,
the next XMPP Council Meeting will take place on Wednesday, July 27
2022 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
a) Proposed XMPP Extension: Bookmark Pinning
https://xmpp.org/extensions/inbox
301 - 400 of 578 matches
Mail list logo
