Re: [Standards] MAM Sync Strategies

2021-08-31 Thread Thilo Molitor
Yes, if you add an already used account to a fresh install of Monal, it will 
not show any old history.
But you can the the "pull to load" feature in an open chat to load old 
messages not already present in the local history via MAM.

While the "before" may not strictly be necessary, it makes the intention of 
the code clearer.

-tmolitor


Am Samstag, 28. August 2021, 03:01:00 CEST schrieb Sam Whited:
> I may have misunderstood, but if we're only fetching the last message
> the first time, do you start out with no history? Also, why set "before"
> at all if it's only one message, the direction won't matter, no?
> 
> —Sam
> 
> On Fri, Aug 27, 2021, at 09:34, Thilo Molitor wrote:
> > When the user first sets up a new account, we query the archive with
> > end= and RSM {max=1, before=""}
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


[Standards] UPDATED: XEP-0001 (XMPP Extension Protocols)

2021-08-31 Thread XSF Editor
Version 1.24.0 of XEP-0001 (XMPP Extension Protocols) has been
released.

Abstract:
This document defines the standards process followed by the XMPP
Standards Foundation.

Changelog:
Change "Draft" to "Stable". (ssw)

URL: https://xmpp.org/extensions/xep-0001.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.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


[Standards] XMPP Council Agenda 2021-09-01

2021-08-31 Thread Jonas Schäfer
Hi everyone,

The next XMPP Council Meeting will take place on 2021-09-01 at 15:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the 
discussions.

This agenda is composed from:

- Editor notifications to standards@
- xsf/xeps GitHub PRs marked as Needs Council
- xsf/xeps GitLab MRs marked as Needs Council
- Suggestions directly sent to me (see below)

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash on-list or directly to me if you think something is 
missing.

3) Editor’s Update

A big one: %s/Draft/Stable/g. See the other mail.

4) Items for voting

None.

5) Pending Votes

- Dave on PR#1096 (XEP-0060: remove exception for last item when purging a 
node)

6) Date of Next

7) AOB

8) Close

End of Agenda.

Note that I am aiming for 30 minutes, but meetings may be extended as 
necessary if all council members agree.

Meetings are normally held every Wednesday at 15:00 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom.
Meetings are open, and anyone (XSF Member or not) may attend, though 
only XMPP 
Council members may vote. Relevant comments from the floor are 
welcomed.

Using your web browser, you can join anonymously via
https://xmpp.org/chat?council

Note that conversations in the room are logged publicly at
https://logs.xmpp.org/council/

If you have suggestions for an agenda item, you can message me via XMPP 
or email at this address or at jo...@zombofant.net.

I aim to publish the Agenda on the day before the Council meeting before 
19:00Z.

Stay safe, smart & healthy,
Jonas


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


[Standards] Stable is the new Draft

2021-08-31 Thread Jonas Schäfer
Hi everyone,

There have been lots of discussions[citation needed] (feel free to trawl the 
list archives yourself... :) ) on the wording we use for our specifications. 
The term "Draft" for our non-Final but also non-Experimental standards has 
been adopted from our "mother" organization, the Internet Engineering Task 
Force. The IETF has since abandoned that term.

Yet, it remains with us. In the recent years it has been a source of 
confusion[citation needed] about this term by newcomers and people not 
familiar with the XMPP ecosystem. They thought that a Draft Standard may not 
be ready for deployment (despite the fancy green text saying otherwise) or 
that it may change substantially, both of which are decidedly untrue for our 
documents in Draft state.

So... The day has finally come. Thanks to Sam who stood up and proposed a pull 
request to update the wording in XEP-0001. As of today, our formerly "Draft" 
standards are called "Stable".

I am sure there will be some hitches on that road. There is some tooling to 
iron out, but this first update immediately patches the view of all XEP 
documents we publish (old versions in the attic will stay as they are).

I hope your are as happy about this as I am :). (or at least not as angry or 
sad about it as I am happy about it, that'd be a start already)

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


Re: [Standards] XEP-0372 references pointing to different elements in same stanza

2021-08-31 Thread Jonas Schäfer
Hi JC,

This has somehow slipped past me.

On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:
> So, if you have a stanza with for example, both "subject" and "body"
> tags, we can have references for both, and use the "anchor" attribute as
> follows (I hope this comes out formatted properly once sent):
> 
> 
>  Attention Bart Simpson
>  Please hand in your homework before the end of the
> day
>  
> 

What about messages with multiple  elements disambiguated by xml:lang? 
Could some conceivably contain a mention while others don't? Does this require 
replicating the mention element all over? Same question for .

Besides that, I don't think that adding an attribute to an element in this way 
is really acceptable.

I would prefer an approach which identifies the XML element without having to 
modify the XML being referenced. Libraries which currently represent body as a 
(mappnig of language tags to) string(s) would now need extra magic in order to 
be able to set ID attributes on those. This feels like a quite major change, 
and not just to References, but to literally everything else.

kind regards,
Jonas

   [1]: https://www.w3.org/TR/REC-xml/#id

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___