[Standards] Re: Proposed XMPP Extension: Chat notification settings

[Timothée Jaussoin]

Hi,

I remember that I implemented a few years ago something very similar in 
Movim but never standardized it, it's maybe the time to do it.


Here is my way of doing it.



Miho






From what I see in the XEP, it's really close:



"never", "always", "on-mention" for the XEP and "never", "always", 
"quoted" for my implementation.


Happy to see that we came up with the same idea and proposal. Once this 
XEP will move forward I'll update my code to implement it accordingly :)


Regards,

edhelas

Le 05/06/2024 à 12:50, Daniel Gultsch a écrit :

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Chat notification settings
Abstract:
This document defines an XMPP protocol extension to synchronise per-
chat notification settings across different clients.

URL:https://xmpp.org/extensions/inbox/notification-filter.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list --standards@xmpp.org
To unsubscribe send an email tostandards-le...@xmpp.org___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

[Timothée Jaussoin]

Le 02/11/2022 à 18:12, Goffi a écrit :

Hi edhelas, thanks for your feedback

Le mercredi 2 novembre 2022, 13:21:01 CET Timothée Jaussoin a écrit :


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.

I agree about maintaining compatibility, as long as we are based on Atom, we
have to keep this text version, even if it's using bandwidth for nothing.


Great :)




- 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...

I still don't think that it's a good way to do this: here images are just http
links, while with XEP-0447 we can associate links and/or jingle and/or
whatever with all metadata and thumbnails needed, and it's possible to add a
way to link a blog post to images.


Again, this is pure metadata and a way to help clients to see how they 
should handle the node. And again, I don't see why we can't have both 
way of supporting pictures in the same item.


I am handling pictures in Movim this way for close than 10 years now, 
Atom fits perfectly and is super easy to handle when you want to inject 
external feeds or transform a Pubsub node into a simple HTTP Atom 1.0 
url. In any case, even if the item contains XEP-0447 elements I'll still 
declare those pictures as attachment to ensure proper Atom compatibility.



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).

'pubsub#type' would be"http://www.w3.org/2005/Atom;  in any case here, I don't
see how you would use it to get comment nodes or gallery node. You would have
to add an other metadata for that (which can be done).

Regarding comment nodes, I think that to do it properly we should fix pubsub
collections and put blog + comments nodes in the same collection. Using filters
and prefixes for nodes is really ugly workaround, and we can end-up with
comments node persisting while a parent blog has been deleted.


Lets not over-engineer things there.

I can hardly have proper support of Pubsub server side, even after years 
of work. Asking to have those extra complexity is a perfect way to be 
sure that I end up not having those feature before a few more years.


I didn't specified any Comments section in this XEP for this exact 
purpose, keep things simple and straigtforward.


The goal of this XEP is basically to specificy a properly a generic way 
of having social feeds on XMPP Pubsub (PEP or services) and ensure that 
I don't end up with this weird "it's Microblog but not really" thing 
that I have already for years.


The purpose of using pubsub#type and those Profiles is having a simple 
way to declare and use nodes that can fits the different types of social 
feeds that we see nowadays (Microblog like Twitter or Mastodon, 
gallery/pictures based like Tumblr or Instagram, news-based like 
Facebook or LinkedIn...).





Regarding the link with XEP-0447: Stateless file sharing I don't see why
 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 '' and another one with
'' for example :) ).

Then you would be mixing atom and XEPs material, it doesn't feel right.
I believe that we need a proper protoXEP to handle photo galleries, probably
something like XEP-0214 but with XEP-0447 payloads instead.


We are already doing it, it is definitely not an issue to embed other 
namespaces within Atom, Geotagging for example 
https://xmpp.org/extensions/xep-0277.html#geotagging


That's the exact purpose of XML, complete features next to or within others.

You have plenty of other examples in chat .

This XEP 'urn:xmpp:gallery:0' is about defining a "social feed that is 
containing at least one picture per Atom item". I'm sure

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

[Timothée Jaussoin]

d 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 
 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 '' and another one with 
'' 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: standards-unsubscr...@xmpp.org
___

Re: [Standards] DOAP files for XMPP implementations

[Timothée Jaussoin]

Hi,

This looks awesome :) Thanks for the good work !

Regards,

edhelas

Le 01/01/2021 à 22:38, Emmanuel Gil Peyrot a écrit :

Hello,

On Sat, Jul 27, 2019 at 05:44:37PM +0200, Emmanuel Gil Peyrot wrote:

Hello,

During the last sprint in Lyon[1] we worked on finishing the DOAP
proposal I sent to this list two years ago[2].

With now a few clients having written and published a DOAP file, it
feels like the right time to aggregate them on xmpp.org and start using
it in our projects.

I have made a pull request[3] towards that, so implementations can start
advertising their DOAP URL during renewal.  It may become a requirement
for further renewal at a later point, but this is entirely experimental
for now.

Comments welcome. :)

[1] 
https://bouah.net/2019/07/new-sprint-new-goodies/#doap-description-of-a-project
[2] https://mail.jabber.org/pipermail/standards/2017-August/033123.html
[3] https://github.com/xsf/xmpp.org/pull/594

I have now written a proof of concept[1] of how the integration of our few
DOAP files would look like at xmpp.org, there is a backend which exposes
just the data we need, and a JS script which presents that on the
website, without any additional dependency.

The code is available here[2].  I haven’t tried integrating it with
Pelican yet, but it’s just one script tag to add to a single page, and
for the XEPs another script to add to the XSLT, so that shouldn’t be
much work if we decide to go with it.

Feedback welcome!

[1] https://linkmauve.fr/extensions/
[2] git clone https://git.linkmauve.fr/xmpp-doap.git


___
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
___

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

[Timothée Jaussoin]

Hi,

This is indeed a really nice XEP that could have a big impact during the 
connection or reconnection.


I was actually wondering if the mechanism could be extended to the 
Roster presences as well? I can imagine that server side (and by 
extension client side as well) the implementation would not be that 
different.


When you have a big Roster like my account (~450 contacts) it could save 
a few seconds after the authentication.


Regards,

Timothée Jaussoin

On 31/03/2020 20:35, Jonas Schäfer (XSF Editor) wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: MUC presence versioning
Abstract:
This specification defines a versioning mechanism which reduces the
amount of presence traffic in a XEP-0045 MUC

URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
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
___

Re: [Standards] PupSub max_items field has no "max" value

[Timothée Jaussoin]

Hi,

One little precision, I've also added the multi-items feature to 0060 a 
few months ago. This allows clients to know if servers actually supports 
more than one item per node. Some servers are actually basing their 
Pubsub implementation on PEP and only limit max_items to 1 without 
actually telling it.


But I think there's a way to make clients work together on Pubsub 
configurations as well. Basically we simply have to set a fix max_items 
in the XEP itself and enforce the configuration server side (and maybe 
expose it to the clients this way). It's already possible to do it on 
ejabberd. This also prevents some clients to change some node 
configuration and, for example, expose some content publicly or destroy 
some.


  mod_pubsub:
    force_node_config:
  "eu.siacs.conversations.axolotl.*":
    access_model: open
  "storage:bookmarks":
    access_model: whitelist
  "urn:xmpp:microblog:0":
    max_items: 5
    access_model: presence
    notify_retract: true

I have lost many times Movim nodes configuration because of some 
misconfigured clients :p


Regards,

edhelas

On 28/09/2019 20:12, Philipp Hörist wrote:

Hi,

There is currently no value that says make it the maximum the server 
supports.


This causes some problems, for example when we want to store bookmarks 
in different items like in XEP-0402 proposed.


Default on most servers is max_items=1. So first i try with publish 
options and already here its not clear what value i should set for 
max_items. There is no way to discover what the amount the server 
supports is, so i take an arbitrary number i think is good.


But a different client might think another number is better, so on 
each publish each client pulls the node configuration and reconfigures 
the node to whatever value he finds useful.


This looks like a bad process. Usually i want to conifgure a node 
once, and not every few days because another client thinks a different 
config is better.


Writing max_items down in the XEP is also not optiimal. We run into 
the same problem if we later change the number in the XEP. Older 
clients will configure the node always back to where it was.


I see the same problem with item_expiry, if a server supports that 
suddenly it gets impossible to have a item not expire.


Now we could imagine setting the value to 0 means forever or max. But 
i didnt find this documented anywhere.


Regards
Philipp



___
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
___

Re: [Standards] Council Minutes 2019-02-27

[Timothée Jaussoin]

Le 06/04/2019 à 10:19, Jonas Schäfer a écrit :

On Mittwoch, 13. März 2019 16:57:07 CEST Kevin Smith wrote:

On 2 Mar 2019, at 18:56, Tedd Sterr  wrote:

3a) PR #758 - XEP-0060: Expose pubsub#access_model and
pubsub#publish_model - https://github.com/xsf/xeps/pull/758
<https://github.com/xsf/xeps/pull/758> Jonas assumes this is still
optional, so that existing services aren't suddenly non-compliant; Link
confirms.

As far as I can tell, this is inside an if you do this (OPTIONAL) you SHOULD
include all the fields, so it’s not clear to me that this is true.

I think I should -1 on that basis, but hoping that someone tells me I’ve
misunderstood.

I am going over the open PRs and came across this.

So my understanding is that node configuration is dynamic and the XEP lists a
lot of fields which may or may not be supported. My understanding is that a
client can not rely on all of the fields to be there anyways:


If metadata is provided, it SHOULD include values for all configured options
as well as "automatic" information such as the node creation date, a list of
publishers, and the like.

So I read it this way:

- A client cannot rely on a server providing all configured options anyways.
- pubsub#access_model and pubsub#publish_model exist and are configuration
options.
- A server SHOULD include configuration options in that form. The current
example do not show the two existing options. So one could read this PR as
making the example more compliant.

I don’t think this is a breaking change either way; services may support or
not-support arbitrary node configuration options anyways, and clients *have*
to deal with stuff missing in any form in pubsub anyways.

Please correct me if I’m wrong.

kind regards,
Jonas

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


Thanks for the review Jonas,

This is exactly how I saw that change in the XEP yes :)

Regards,

Timothée Jaussoin

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

Re: [Standards] Is the World Ready for Compliance Suites 2019?

[Timothée Jaussoin]

What about using a proper XEP like SIMS 
(https://xmpp.org/extensions/xep-0385.html) for that case?


This look like a hack to me.

Le 06/03/2019 à 22:05, Georg Lukas a écrit :

* Tedd Sterr  [2019-03-06 21:30]:

Naysayers are invited to comment now, or forever hold their piece.

because I love to be the naysayer, here is one:

"Modern" clients are using a small subset of XEP-0066, namely §3, to
communicate inline images in messages. A small subset of those clients,
furthermore, requires the  value to be equal to the message 
for this to work, apparently to enforce compatibility with legacy
clients.

Example 1: "Modern" Use of OOB for Inline Images

   https://xmpp.org/theme/images/xmpp-logo.svg
   
 https://xmpp.org/theme/images/xmpp-logo.svg
   


While XEP-0066 is less than ideal for the purpose of embedding images,
and the body=url requirement isn't written down anywhere, it is
something that client developers should know about, at least to
implement it on the receiving side.


Georg

___
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
___

Re: [Standards] Generalisation of XEP-xxxx: MUC Avatars

[Timothée Jaussoin]

Le mardi 25 septembre 2018 à 19:49 +0200, Timothée Jaussoin a écrit :
> I just reviewed the XEP-: MUC Avatars and I would like to discuss some 
> ideas about it before proposing adjustments.
> 
> The core idea of this XEP is to expose the Vcard hash in the bare MUC JID 
> disco#info and notify it using a message 104.
> This is a really specific use case that solves a really specific problem.
> 
> However the method that is used in this XEP to store this hash could be 
> generalized to other cases.
> 
> I see two things there:
> - How are we storing the avatar hash (here in a specific field in disco#info)
> - How this hash is advertised to the subscribers
> 
> disco#info is a pretty generic feature in XMPP that is actually already 
> applied to most of the resources available on the network
> including:
> - MUC JIDs
> - Users JIDs
> - Pubsub nodes
> 
> What I'd like to propose is to generalize this XEP to allow this method to be 
> used across all those resources, this will allow to
> have
> a unified method (it maybe sounds like https://xkcd.com/927/) to handle the 
> retrieval of Avatars and also finally allow Pubsub nodes
> to
> have an avatar (and Vcard information as well if possible, see my last point).
> 
> This brings me to the second part of my proposal. How to advertise the change.
> - For MUC, I'd suggest to stick with the status code='104' even if I'd prefer 
> to use XEP-0153 presences for that
> - For Users JIDs, simply stick with XEP-0153
> - For Pubsub nodes it could also reuse XEP-0153 in a Pubsub notification as a 
> payload
> 
> Last proposal would not be to mention only Avatar but simply Vcard 
> (vcard-temp in this case) then we could put more metadata in this
> payload (add an address to a Pubsub node for example) but I'd like to have 
> more feedback on that one.
> 
> In any cases I'll try to formalize those proposals in a PR to this XEP :)
> 
> Regards,
> 
> Timothée Jaussoin
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

Sorry for the delay but I just published a PR that add the proposed changes to 
the XEP.
Feel free to comment them https://github.com/xsf/xeps/pull/713.

Regards,

Timothée Jaussoin

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

[Standards] Generalisation of XEP-xxxx: MUC Avatars

[Timothée Jaussoin]

I just reviewed the XEP-: MUC Avatars and I would like to discuss some 
ideas about it before proposing adjustments.

The core idea of this XEP is to expose the Vcard hash in the bare MUC JID 
disco#info and notify it using a message 104.
This is a really specific use case that solves a really specific problem.

However the method that is used in this XEP to store this hash could be 
generalized to other cases.

I see two things there:
- How are we storing the avatar hash (here in a specific field in disco#info)
- How this hash is advertised to the subscribers

disco#info is a pretty generic feature in XMPP that is actually already applied 
to most of the resources available on the network
including:
- MUC JIDs
- Users JIDs
- Pubsub nodes

What I'd like to propose is to generalize this XEP to allow this method to be 
used across all those resources, this will allow to have
a unified method (it maybe sounds like https://xkcd.com/927/) to handle the 
retrieval of Avatars and also finally allow Pubsub nodes to
have an avatar (and Vcard information as well if possible, see my last point).

This brings me to the second part of my proposal. How to advertise the change.
- For MUC, I'd suggest to stick with the status code='104' even if I'd prefer 
to use XEP-0153 presences for that
- For Users JIDs, simply stick with XEP-0153
- For Pubsub nodes it could also reuse XEP-0153 in a Pubsub notification as a 
payload

Last proposal would not be to mention only Avatar but simply Vcard (vcard-temp 
in this case) then we could put more metadata in this
payload (add an address to a Pubsub node for example) but I'd like to have more 
feedback on that one.

In any cases I'll try to formalize those proposals in a PR to this XEP :)

Regards,

Timothée Jaussoin

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

Re: [Standards] XEP-0060: Item ordering

[Timothée Jaussoin]

Le mercredi 08 août 2018 à 16:32 +0100, Matthew Wild a écrit :
> On 8 August 2018 at 16:17, Peter Saint-Andre  wrote:
> > On 8/8/18 3:17 AM, Philipp Hörist wrote:
> > > I always thought the most recent refers to the publish date/time of the
> > > item, hence if i override a item it also changes the updated time/date
> > > and it becomes the most recent
> > 
> > That seems reasonable. So it's really "last modified item". I'm curious
> > what Ralph thinks.
> 
> Me too.
> 
> I personally have always shared Philipp's interpretation. A publish of
> an item is a publish, whether another item already existed with that
> id or not.

So it's a https://xkcd.com/1172/ case for me.
Having a "social network" implementation using Pubsub this behavior is going 
against the current flow that I'm using in Movim.
If you edit an article on a social network or a blog it shouldn't move back to 
the top of your feed. It is also, afaik, how ejabberd is
handling it.

In both cases, does the disco#items 
(https://xmpp.org/extensions/xep-0060.html#entity-discoveritems) and query 
items (
https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome) IDs 
order should be consistent then? If it's the case then
using RSM on disco#items should be enough to "refresh" what the client missed 
on a node (give me all the items published after the ID
of the last updated item that I have in my cache) without actually having to 
compare the payloads.

I'm also wondering if this affects https://xmpp.org/extensions/xep-0395.html.

Regards,

Timothée

> 
> I'd say this interpretation also makes the most sense if you consider
> the perspective of someone subscribed to the node. Requesting the
> items will return the same items in the same order that you would have
> received them while subscribed, with the obvious exception of items
> that have been replaced.
> 
> Regards,
> Matthew
> ___
> 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
___

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Timothée Jaussoin]

Hi everyone, 

Just bouncing back this discussion again. I'd like to see what we can decide at 
the moment based on the information that we have here.
I'll add a couple of information there, those are simple technical limitation 
that will guide our decisions regarding this problem.

ejabberd is restraining the size of the JIDs, node IDs and many other things to 
varchar(191) for MySQL, I'm doing similar things in
Movim regarding the key size limit in MySQL (it's less a problem for the other 
SQL databases).

So we already have in the wild some servers that will not accept those long 
JIDs and IDs.

Some web app that are using XMPP as a backend are mapping Pubsub resources to 
URLs, like Movim or SàT (afaik), here's an example https:
//nl.movim.eu/?node/pubsub.movim.eu/Movim/a-new-release-is-coming-help-up-with-the-translations-WM4Yrf.
 On my side I'm slugifying
things to make those node and item ids easier to read but I'm expecting to have 
some escaping problems for some cases.

Related to that, we have Bookmark 2 that is in discussion 
https://xmpp.org/extensions/inbox/bookmarks2.html. This XEP defines that
"Each item SHALL have, as item id, the Room JID of the chatroom". This means 
that Pubsub item ids have the same definition as JIDs?

On my side I'd propose to restrict JIDs to something shorter (like 128 UTF-8 
characters) to be sure that those can be stored and
intexed properly in databases and to define that all the Pubsub/PEP IDs are 
having the same definition as JIDs. 

Regards,

Timothée Jaussoin

Le mercredi 07 mars 2018 à 09:20 -0700, Peter Saint-Andre a écrit :
> On 3/6/18 1:02 AM, Jonas Wielicki wrote:
> > Hi Peter,
> > 
> > Thank you very much for the clarification, comments inline.
> > 
> > On Dienstag, 6. März 2018 02:59:04 CET Peter Saint-Andre wrote:
> > > On 3/5/18 12:17 AM, Jonas Wielicki wrote:
> > > > On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote:
> > > > > On 3/4/18 10:54 AM, Jonas Wielicki wrote:
> > > > > > On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> > > > > > > If we want to specify this, I would recommend the 
> > > > > > > UsernameCaseMapped
> > > > > > > profile defined in RFC 8265.
> > > > > > > 
> > > > > > > However, there's a twist: if a node ID can be a full JID, then do 
> > > > > > > we
> > > > > > > want to apply the normal rules of RFC 7622 to all the JID parts,
> > > > > > > instead
> > > > > > > of one uniform profile such as UsernameCaseMapped to the entire 
> > > > > > > node
> > > > > > > ID?
> > > > > > > For instance, the resourcepart of a JID is allowed to contain a 
> > > > > > > much
> > > > > > > wider range of Unicode characters than is allowed by the
> > > > > > > UsernameCaseMapped profile of the PRECIS IdentifierClass (which 
> > > > > > > we use
> > > > > > > for the localpart).
> > > > > > > 
> > > > > > > Given that a node ID can be used for authorization decisions, I 
> > > > > > > think
> > > > > > > it's better to be conservative in what we accept (specifically, 
> > > > > > > not
> > > > > > > allow the wider range of characters in a resourcepart because
> > > > > > > developers, and attackers, could get too "creative").
> > > > > > 
> > > > > > I would argue that adding those restrictions / any kind of string
> > > > > > prepping
> > > > > > to XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at
> > > > > > least,
> > > > > > as you mentioned (depending on the data).
> > > > > 
> > > > > I would argue that not specifying normalization rules is a security 
> > > > > hole
> > > > > (e.g., allowing an attacker to gain unauthorized access to a node). 
> > > > > Just
> > > > > because we should've done this years ago doesn't mean we can fix it 
> > > > > now.
> > > > 
> > > > Hm, okay, I don’t seem to understand the attack vector. Could you spell 
> > > > it
> > > > out more clearly to me?
> > > 
> > > Here's a true, non-XMPP example: I have the account stpe...@gmail.com.
> > > However, Google ignores "." in the localpart. Therefore I receive some
> > > email messages intended for st.pe...@gmail.c

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Timothée Jaussoin]

Hi,

Based on the discussion we had on this ML a couple of weeks ago ([Standards] 
What is the size limit of node and item ids in XEP-0060:
Publish-Subscribe? 
https://mail.jabber.org/pipermail/standards/2018-March/034410.html).

I see that this XEP define the item ids of the Pubsub nodes this way: "Each 
item SHALL have, as item id, the Room JID of the chatroom".

Are we sure that the format accepted by item ids follow the same rules as the 
ones in JIDs (size wise, character encoding wise…)? This
question is also about having other XEPs in the future that can handle items 
the same way (for example if we define a Pubsub Nodes
Bookmarks XEP).

In a previous XEP that was doing something very similar I simply used a hash to 
ensure that https://xmpp.org/extensions/xep-0330.html.

Regards,

Timothée Jaussoin

Le dimanche 18 mars 2018 à 13:34 +, Jonas Wielicki a écrit :
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specification defines a syntax and storage profile for keeping a
> list of chatroom bookmarks on the server.
> 
> URL: https://xmpp.org/extensions/inbox/bookmarks2.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Timothée Jaussoin]

Hi,

Would it be possible to extend this to also allow the storage of Pubsub 
subscriptions (reusing the urn:xmpp:pubsub:subscription namespace defined 
in XEP-0330 https://xmpp.org/extensions/xep-0330.html)? 

This would allow 'social clients' like Movim or Salut à Toi to store their 
favorite Pubsub nodes in the Bookmarks as well.

Regarding the fact the each of them is store atomically this shouldn't be 
an issue to store client specific bookmarks namespaces on this node 
(we could imagine new way in the future to store browser bookmarks, 
maps location bookmarks…).

Regards,

Timothée Jaussoin

Le dimanche 18 mars 2018 à 13:34 +, Jonas Wielicki a écrit :
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specification defines a syntax and storage profile for keeping a
> list of chatroom bookmarks on the server.
> 
> URL: https://xmpp.org/extensions/inbox/bookmarks2.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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
___

Re: [Standards] Private Data storage discrepancy

[Timothée Jaussoin]

Hi Guus,

Thanks for the work on Bookmarks :) Indeed that was, I think, a mistake.
On my side I followed the structure of the 0048 
(https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Bookmark.php#L30) 
which, I
think is more logical (the storage:bookmarks namespace is defined with this 
 wrapper).

Regards,

Tim

Le vendredi 16 mars 2018 à 12:03 +0100, Guus der Kinderen a écrit :
> Hello,
> 
> I'm working on migrating Bookmarks 
> (https://xmpp.org/extensions/xep-0048.html) from Private XML Storage 
> (https://xmpp.org/extensions/
> xep-0049.html) to PEP (https://xmpp.org/extensions/xep-0223.html). I'm was 
> surprised to find a difference between the Pubsub node
> defined in 0048 example 3 (the published item root element is 'storage', that 
> itself contains 'conference') and 0233's example 3 (the
> published item root element is 'conference' directly, without the wrapping 
> 'storage'). I expected those two examples to have the same
> structure. What's going on there?
> 
> Regards,
> 
>   Guus
> ___
> 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
___

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Timothée Jaussoin]

Le jeudi 01 mars 2018 à 07:10 -0700, Peter Saint-Andre a écrit :
> On 3/1/18 1:07 AM, Jonas Wielicki wrote:
> > On Donnerstag, 1. März 2018 08:52:29 CET Florian Schmaus wrote:
> > > On 01.03.2018 01:17, Peter Saint-Andre wrote:
> > > > On 2/28/18 3:18 PM, Timothée Jaussoin wrote:
> > > > > Hi,
> > > > > 
> > > > > I came across a database limitation while implementing Pubsub in 
> > > > > Movim.
> > > > > 
> > > > > I'd like to know if we have a limitation for the size of the node and
> > > > > items ids in Pubsub (like we have for the JIDs). Also do we have some
> > > > > specific forbid characters, basically what is the format of such
> > > > > attributes? If noting is already specificed I think that it would be
> > > > > wise to update the 0060 to do so.> 
> > > > 
> > > > My inclination is to specify a length of 1023 octets
> > > 
> > > Which would break applications and protocols using JIDs as node or item
> > > identifier. This includes for example MIX. If we want to allow this, we
> > > need at least (3x1023)+2 octets, and then I would probably go for 4096
> > > octets.
> > 
> > This is bikeshedding territory. But given that databases have limits on the 
> > size of keys, using as many as needed and as few as possible octets (the 
> > 3071 
> > you quoted) is probably sensible.
> > 
> > Do those protocols use bare or full JIDs? If they only use bare and if we 
> > agree that full JIDs (due to their transience) do not make sense, the limit 
> > could conceivably be as low as 2047, which is probably comfortable for 
> > databases to handle.
> 
> A full, especially non-client JID need not be transient, so I suppose
> we'd set it to 3071 (not sure why we'd need 4096 other than the fact
> it's a power of 2):
> 
> https://tools.ietf.org/html/rfc7622#section-3.1
> 
> Peter
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

Hi,

Thanks for the answers. I'm fine for the 3071 limitation, so we can set it both 
for the Pubsub nodes id and Pubsub items it?
If yes I'm ok to do a PR on the 0060 to specify that. I'm also wondering if 
there is a specific way of declaring such string
limitations, are you aware of any other XEPs that specify such things?

Regards,

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

[Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Timothée Jaussoin]

Hi,

I came across a database limitation while implementing Pubsub in Movim.

I'd like to know if we have a limitation for the size of the node and items ids 
in Pubsub (like we have for the JIDs).
Also do we have some specific forbid characters, basically what is the format 
of such attributes?
If noting is already specificed I think that it would be wise to update the 
0060 to do so.

Regards,

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

Re: [Standards] Adding logo to MUC and PubSub node

[Timothée Jaussoin]

Le jeudi 08 février 2018 à 08:26 +0300, Evgeny Khramtsov a écrit :
> Wed, 7 Feb 2018 22:16:30 +0100
> "W. Martin Borgert"  wrote:
> 
> > Hi,
> > 
> > this is an idea mainly for the "social network" aspect of XMPP:
> > A logo for a MUC or for a PubSub node, similar to a user avatar.
> > 
> > Such a logo, emblem, or symbol can be a good indicator for users
> > to find the right MUC or PubSub node in a social network
> > application or graphical XMPP client.
> > 
> > How about introducing two configuration variables, one in
> > https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig:
> > 
> > var='muc#muc_logo'
> > 
> > And the second one in
> > https://xmpp.org/extensions/xep-0060.html#owner-configure:
> > 
> > var='pubsub#node_logo'
> > 
> > The value should be a  element from
> > https://xmpp.org/extensions/xep-0221.html.
> > 
> > IMHO, the value should be restricted to
> >  1. images, or would a sound make sense? Maybe...
> >  2. inline data, so that a link to a web resource cannot be
> > abused for snitching IP addresses
> > 
> > What do you think?
> 
> This is the same as to provide vCards by the service (which is
> implemented in ejabberd for MUCs for example), and has the same
> drawback: there is no way to tell clients that your logo has updated.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

For the MUC maybe, but I'm fine with having this solution for the moment while 
MIX is designed to have a more proper one with real-
time.
For Pubsub, this is already the case with node metadatas, this URL can come 
with the title, description and many other info.

In the end I don't think that it's a big issue to have those info requested 
manually, having a cache of a few hours on the clients is
an OK solution for me at the moment.

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

Re: [Standards] Adding logo to MUC and PubSub node

[Timothée Jaussoin]

Hi,

That would indeed be a wonderful idea to add to the standard :)
If such thing is standardized I'd be glad to add it in Movim (for the MUC and 
Pubsub part).

Regards,

edhelas

Le mercredi 07 février 2018 à 22:16 +0100, W. Martin Borgert a écrit :
> Hi,
> 
> this is an idea mainly for the "social network" aspect of XMPP:
> A logo for a MUC or for a PubSub node, similar to a user avatar.
> 
> Such a logo, emblem, or symbol can be a good indicator for users
> to find the right MUC or PubSub node in a social network
> application or graphical XMPP client.
> 
> How about introducing two configuration variables, one in
> https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig:
> 
> var='muc#muc_logo'
> 
> And the second one in
> https://xmpp.org/extensions/xep-0060.html#owner-configure:
> 
> var='pubsub#node_logo'
> 
> The value should be a  element from
> https://xmpp.org/extensions/xep-0221.html.
> 
> IMHO, the value should be restricted to
>  1. images, or would a sound make sense? Maybe...
>  2. inline data, so that a link to a web resource cannot be
> abused for snitching IP addresses
> 
> What do you think?
> 
> TIA & Cheers
> ___
> 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] Re : XEP-0054 and XEP-0292 (vCard)

[Timothée Jaussoin]

Hi,

We do in Movim (https://movim.eu/) using the 'urn:xmpp:vcard4' PEP node :)

Regards,

Timothée Jaussoin 

Le dimanche 01 octobre 2017 à 18:10 +0200, Philipp Hörist a écrit :
> Thanks,
> 
> Are you aware of any client that supports XEP-0292?
> 
> 2017-10-01 17:56 GMT+02:00 Florian Schmaus <f...@geekplace.eu>:
> > On 01.10.2017 12:56, Philipp Hörist wrote:
> > > Thanks for the answer.
> > > Maybe i wasnt very clear what my question was.
> > >
> > > I want to use grouping with XEP-0054>
> > > neither 0054
> > > nor https://tools.ietf.org/html/draft-dawson-vcard-xml-dtd-01 speaks of
> > > grouping or has examples.
> > 
> > RFC 6350 and RFC 6351 do.
> > 
> > But I don't think that standards@xmpp.org is the right venue discussing
> > vCards, as it is an IETF RFC. Unfortunately I'm not sure where to point
> > you at. The Vcarddav WG [1] is concluded.
> > 
> > Side node: draft-dawnson-vcard-xml-dtd-03 is from 1998.
> > 
> > > 1. Does that mean its not supported?
> > 
> > It appears that XEP-0054, using vcard-temp, does support grouping, as
> > the relevant RFC 2426 does also mention it. But the RFC is very vague on
> > the topic.
> > 
> > XEP-0292 using vCard4 does support grouping.
> > 
> > > 2. If it is supported how exactly would an example look like
> > 
> > See RFC 6351 § 5.
> > 
> > - Florian
> > 
> > 1: https://tools.ietf.org/wg/vcarddav/
> > 
> > 
> > ___
> > 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Permanent slots for HTTP Upload

[Timothée Jaussoin]

Hi everyone,

Based on the previous messages I'd like to do a proposal regarding the 
evolution of HTTP Upload.

The idea behind HTTP-Upload was to have this tiny-simple XEP that can handle 
upload of files through HTTP and return an URL that can be
inserted everywhere in XMPP.

It seems that people, like Daniel, are reaching the limits of those features 
and want to extend the XEP.

What I'd like to propose, is to re-use Pubsub/PEP to handle and manage those 
files.

Basically once a file is uploaded using HTTP-Upload, the server creates a new 
item on a designated PEP node (urn:xmpp:files:0 for
example) and notify the publisher using a simple headline.

This PEP node will list all the previously uploaded files, the items could 
contain all the metadata (using something like XEP-0385:
Stateless Inline Media Sharing (SIMS) for example).

This way, at any moment, the user can see what files are stored on the server 
and can easily manage/delete them. A hard-limit can also
be put on the number of those items to only keep the latest 100 files uploaded 
(for example).

All those mechanism are relying on existing XEPs and will require only a small 
adaptation on the servers and clients to handle that.

I'm open to any proposal but I'd strongly prefer to re-use and push existing 
standards and defined XML namespaces than creating
something from scratch for our needs. 

Regards,

Timothée Jaussoin

Le vendredi 08 septembre 2017 à 10:58 +0200, Daniel Gultsch a écrit :
> Hi all,
> 
> when I first came up with HTTP Upload it was intended to also provide
> storage space for avatars and other permanent and public information.
> The introduction even mentions this.
> 
> However most servers currently have rather low retention periods of 10
> days or 30 days (which is fair). Uploading an avatar for example under
> those conditions however isn't very feasible.
> 
> That's why I propose to add the ability to optionally request slots
> that are permanent.
> Those permanent slots would have multiple types (avatar,...) and would
> always overwrite each other.
> 
> Syntax would probably look something like this.
> 
> 
> 
> But I have a few questions:
> 
> Do you think these types should be registered?
> Should we use types at all? Or rather have some other limitation on
> permanent slots? (Like user can only have 10? And old ones will always
> be overwritten)
> 
> cheers
> Daniel
> ___
> 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
___

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

[Timothée Jaussoin]

Hello everyone,

I've created a page on the Wiki for the project 
https://wiki.xmpp.org/web/T-DOSE_2017. 
If you are interested to come, do a conference, a XMPP meetup or something 
related, please put it on this page :)

Regards,

Timothée

Le lundi 31 juillet 2017 à 12:18 +0200, Guus der Kinderen a écrit :
> Hi Timothée,
> 
> Thanks for taking the time to organize this! I'd certainly be interested in 
> attending.
> 
> As for XSF support: what exactly do you need? This year, the XSF created the 
> SCAM (somethingsometing, Conferences And Meetups)
> workgroup (of which I may or may not be a part). I am not aware of any 
> activity of that workgroup other than its inception. This
> event might be a good first event to get SCAM-things going though.
> 
> Regards,
> 
>   Guus
> 
> On 30 July 2017 at 22:50, Timothée Jaussoin <edhe...@movim.eu> wrote:
> > Hi everyone,
> > 
> > I'm currently in contact with an organizer of the T-DOSE event. For those 
> > that don't know T-DOSE.
> > 
> >     T-DOSE is a free and yearly event held in The Netherlands to promote 
> > use and development of Open Source Software. During this
> > event
> >     Open Source projects, developers and visitors can exchange ideas and 
> > knowledge. This years event will be held at the Fontys
> >     University of Applied Science in Eindhoven on November 18 and 19.
> > 
> > More info here http://www.t-dose.org/.
> > 
> > I think that it could be a nice opportunity to meet-up there and maybe have 
> > conferences to promote the XMPP protocol :)
> > The organizers told me that they have classrooms available where we could 
> > talk and that they are open for conferences proposal
> > (deadline September 30).
> > 
> > For those that are interested to take part of it and help with the 
> > organization do not hesitate to answer that mail.
> > I don't have a clear idea how we organize our participation into such event 
> > in the XSF, should I create a Wiki page? Is it possible
> > to
> > put it in the agenda for the next meeting?
> > 
> > On my side I can help with the communication with the T-DOSE team, I'm also 
> > interested to propose a conference (around
> > Movim/social-
> > networking on XMPP…) and participate in discussion if we meet-up to talk 
> > about the current XEP in progress.
> > 
> > Kind regards,
> > 
> > Timothée Jaussoin
> > ___
> > 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

[Timothée Jaussoin]

Hello everyone,

I've created a page on the Wiki for the project 
https://wiki.xmpp.org/web/T-DOSE_2017. 
If you are interested to come, do a conference, a XMPP meetup or something 
related, please put it on this page :)

Regards,

Timothée

Le lundi 31 juillet 2017 à 12:18 +0200, Guus der Kinderen a écrit :
> Hi Timothée,
> 
> Thanks for taking the time to organize this! I'd certainly be interested in 
> attending.
> 
> As for XSF support: what exactly do you need? This year, the XSF created the 
> SCAM (somethingsometing, Conferences And Meetups)
> workgroup (of which I may or may not be a part). I am not aware of any 
> activity of that workgroup other than its inception. This
> event might be a good first event to get SCAM-things going though.
> 
> Regards,
> 
>   Guus
> 
> On 30 July 2017 at 22:50, Timothée Jaussoin <edhe...@movim.eu> wrote:
> > Hi everyone,
> > 
> > I'm currently in contact with an organizer of the T-DOSE event. For those 
> > that don't know T-DOSE.
> > 
> >     T-DOSE is a free and yearly event held in The Netherlands to promote 
> > use and development of Open Source Software. During this
> > event
> >     Open Source projects, developers and visitors can exchange ideas and 
> > knowledge. This years event will be held at the Fontys
> >     University of Applied Science in Eindhoven on November 18 and 19.
> > 
> > More info here http://www.t-dose.org/.
> > 
> > I think that it could be a nice opportunity to meet-up there and maybe have 
> > conferences to promote the XMPP protocol :)
> > The organizers told me that they have classrooms available where we could 
> > talk and that they are open for conferences proposal
> > (deadline September 30).
> > 
> > For those that are interested to take part of it and help with the 
> > organization do not hesitate to answer that mail.
> > I don't have a clear idea how we organize our participation into such event 
> > in the XSF, should I create a Wiki page? Is it possible
> > to
> > put it in the agenda for the next meeting?
> > 
> > On my side I can help with the communication with the T-DOSE team, I'm also 
> > interested to propose a conference (around
> > Movim/social-
> > networking on XMPP…) and participate in discussion if we meet-up to talk 
> > about the current XEP in progress.
> > 
> > Kind regards,
> > 
> > Timothée Jaussoin
> > ___
> > 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for participation for a XMPP-based EU Funded project on data portability

[Timothée Jaussoin]

Hi Sam,

I notified the responsible at the Fraunhofer institute and they gives me some 
complementary feedbacks regarding the role of the XSF in
the EAB.

Regarding their role: We would organize 2 Workshops - one at the 
beginning and one when we already have a first version of the prototype. 
We invite the EAB to discuss the projects ideas and outcomes and to get 
feedback from them. To take part, the EAB members do not need to prepare 
anything for the workshop (they do not need to hold a presentation, only 
if they would wish to -- then they would of course be very welcome to do 
so), joining the workshops is enough. The letter of Intent only holds a 
specific name of one of the XSF-members for contact purposes. This does 
not mean, that the person who signs the letter of intent on behalf of 
the XSF needs to join the meeting himself. It also does not need to be 
the same person that is joining the two workshops.
We would pay for the planeticket (within Europe) and hotel for the 
person that represents XSF on the two workshops.

Basically the idea of the EAB is only to attend those two meetings and "advise" 
the members of the project regarding what has been
discussed. In the case of the XSF within this project, it's mostly to give 
feedbacks on the usage of XMPP as a reference protocol for
the GDPR (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), 
this will cover usages like social networking (so Pubsub
related), user data (vCard, avatar, PEP) and possibly IoT.

We would need a signature for the letter of intent before we give the proposal 
(so next week).

Kind regards,

Timothée Jaussoin

Le mercredi 16 août 2017 à 11:50 -0500, Sam Whited a écrit :
> On Thu, Aug 10, 2017, at 04:57, edhelas wrote:
> > *What else are we searching for?*
> > We would be interested in the XSF, as an organization itself, to join 
> > our project´s External Advisory Board. The EAB would meet twice within 
> > the projects duration to discuss the main ideas and outcome of the 
> > project. The travel costs of one XSF-member (hotel and plane) to those 
> > two workshops can be funded.
> 
> It sounds like this is the important part of the proposal as far as the
> XSF is concerned. Having a member of the XSF council on your advisory
> board sounds sensible, but this email was a bit sparse on details.
> 
> What is the role of the EAB as it relates to your project? What are the
> responsibilities of EAB members? Do these responsibilities fall on the
> XSF, or on the individual that volunteers as a representative of the
> XSF? Is there money involved (that would have to pass through XSF hands
> somehow, which might be a liability or require the treasurer being
> involved)?
> 
> Thanks,
> Sam
> ___
> 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] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

[Timothée Jaussoin]

Hi everyone,

I'm currently in contact with an organizer of the T-DOSE event. For those that 
don't know T-DOSE. 

T-DOSE is a free and yearly event held in The Netherlands to promote use 
and development of Open Source Software. During this event
Open Source projects, developers and visitors can exchange ideas and 
knowledge. This years event will be held at the Fontys
University of Applied Science in Eindhoven on November 18 and 19.

More info here http://www.t-dose.org/.

I think that it could be a nice opportunity to meet-up there and maybe have 
conferences to promote the XMPP protocol :)
The organizers told me that they have classrooms available where we could talk 
and that they are open for conferences proposal
(deadline September 30).

For those that are interested to take part of it and help with the organization 
do not hesitate to answer that mail.
I don't have a clear idea how we organize our participation into such event in 
the XSF, should I create a Wiki page? Is it possible to
put it in the agenda for the next meeting?

On my side I can help with the communication with the T-DOSE team, I'm also 
interested to propose a conference (around Movim/social-
networking on XMPP…) and participate in discussion if we meet-up to talk about 
the current XEP in progress.

Kind regards,

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

Re: [Standards] XEP-0163: depend on persistent-items, node-config and publish-options

[Timothée Jaussoin]

+1 for me as well

Regards,

Timothée

Le jeudi 13 juillet 2017 à 12:54 +0200, Jonas Wielicki a écrit :
> On Donnerstag, 13. Juli 2017 11:51:32 CEST Daniel Gultsch wrote:
> > [everything daniel said]
> 
> Yes, please. This will lead to some "PEP complaint" servers to not be PEP 
> complaint anymore, but that is a win in my eyes because PEP without the 
> features you described is rather useless for most of the IM use cases.
> 
> kind regards,
> Jonas
> ___
> 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] Question regarding XEP-0333: Chat Markers

[Timothée Jaussoin]

Hi,

I'm currently doing the implementation of XEP-0333: Chat Markers in Movim and I 
have a question regarding the current XEP and it's
implementation in the client.

1. Introduction: Message Delivery Receipts (XEP-0184) currently provides 
delivery receipts on a per message basis, but it does not
provide any mechanism for the user to indicate that they have read or 
acknowledged the message. and 6. Protocol Format * received --
the message has been received by a client. 


It seems that we have a redundant specification here, even if the flow to send 
those  tags are a bit different (per messages
in XEP-0184 and on the latest one on XEP-0333). 
Here is an example of a message from Conversations received in Movim.



I'd suggest:
 * Or we deprecate the XEP-0184 and keep the current flow of XEP-0333 (that is 
a bit more optimized)
 * Or we remove the  tag part of XEP-0333 and just fully rely on 
XEP-0184 to acknowledge the good reception of those
messages

On my side I'd prefer to deprecate XEP-0184 regarding the small optimisations 
that XEP-0333 brings on the acknowledgement flow.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Timothée Jaussoin]

Hi,
After reading all the discussions related to my pull request it seems that 
there is a consensus on the fact that PEP should not be used
this way to store those OMEMO bundles.I agree to retrieve it and continue with 
the current flow.
Regards,
Timothée Jaussoin 
Le lundi 03 avril 2017 à 07:18 +0200, Remko Tronçon a écrit :
> On 26 March 2017 at 00:01, Timothée Jaussoin <edhe...@movim.eu> wrote:
> > This behavior can be fixed by setting pubsub#deliver_payloads to false in 
> > the 'urn:xmpp:omemo:0' node configuration. 
> 
> Bringing node configuration into a PEP-based protocol sounds like a slippery 
> slope, and is maybe taking it too far. Doesn't this also
> bring in extra complexity and questions like who configures the node and when?
> 
> The current split between data (which no one subscribes to) and metadata 
> (which is subscribed to) makes sense to me, and doesn't rely
> on anything but PEP semantics. This approach is also used in XEP-0084 (User 
> Avatar), which is probably the oldest PEP protocol out
> there.
> 
> Keeping this split seems independent from the discussion whether device IDs 
> (i.e. the metadata) should be published to separate
> items, and that the entire list can be queried for any new clients. XEP-0084 
> also publishes to different item IDs, although it
> doesn't rely on the entire list of metadata to be available, and if a server 
> doesn't support item IDs, avatars would still sort of
> work.
> 
> Remko
> 
> ___
> 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
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Timothée Jaussoin]

Hi,

It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.

Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :
> Hey all,
> 
> this topic has been discussed at the summit and in other venues
> before, 
> and now a proposal to abolish the devicelist and move all bundles
> into 
> separate items in a single PEP node has been submitted. I have raised
> my 
> concerns in those abstract discussions in the past, but now we have 
> something concrete we can discuss.
> 
> https://github.com/xsf/xeps/pull/458/files
> 
> While I recognize that the way we've been using PEP is somewhat 
> unorthodox, I see several severe issues with this newly proposed
> approach.
> 
> Most importantly, this change effectively relies on OPTIONAL/MAY 
> behavior in PEP. PEP/pubsub do not mandate that the server has to
> keep 
> around more than one item per node. Therefore, this change will
> limit 
> the number of OMEMO devices a user can have active at the same time
> to 
> the maximum number of items per PEP node as supported by the server, 
> which in the general case has to be assumed to be 1. The devicelist
> is 
> an absolutely essential component of OMEMO, and it *has to* work 
> properly. Without it, we not only lose multi-device, but have to
> deal 
> with severe reliability issues related to whichever device(s)
> happen(s) 
> to be currently announced or not (i.e. messages only arriving at
> random, 
> possibly frequently changing subsets of devices without the user
> being 
> able to control this at all)
I agree with that and I trully think that this behavior needs to be clarified. 
It seems indeed that this OPTIONAL/MAY in the PEP
extension brought two points of view on how PEP can be seen. To me, if a server 
can store several items per PEP nodes (which is the
case on several XMPP servers already) then I see it as a "Pubsub service" 
available under a user JID.
 
Also, some XEPs like Microblog (0277) and Pubsub-Subscription (0330) are 
already relying on it and are implemented in clients. The work
that we are currently doing to modernize the Bookmark XEP (0048) also replies 
on the fact that each bookmark will be store in different
items under the same PEP node (to prevent the current race-condition issue that 
we have today).

As I understood this behavior was mostly crafted like this because it was 
working on existing servers implementations, especially for
Prosody that doesn't support persistance of items in its current stable release.


> 
> Furthermore, by eliminating the indirection via a separate
> devicelist 
> node and subscribing to all bundles directly, a significant increase
> in 
> traffic overhead is to be expected. Any time a bundle changes, all 
> contacts will receive the entire bundle. This happens frequently in 
> OMEMO. For example, whenever a new session is established, according
> to 
> the XEP, the responder SHOULD change their bundle (removing the used-
> up 
> prekey). Clients might also rotate their signed prekey regularly.
> Any 
> time these things happen, all OMEMO-enabled contacts (and other own 
> devices) will receive the full bundle. Note that in most cases,
> these 
> clients don't care at all about these events. The only times a
> client 
> would actually want to be passively informed about changes is when 
> devices are newly created or removed entirely, which is the vast 
> minority of these events. (For reference, bundles with the suggested 
> number of prekeys (100) are around 9-10kb in size.)
> 

See https://xmpp.org/extensions/xep-0060.html#owner-configure.

This behavior can be fixed by setting pubsub#deliver_payloads to false in the 
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can 
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull 
request to enforce this behavior on node creation.

> This proposal is also internally inconsistent. Some of the
> prescribed 
> behavior makes no sense under this new architecture (e.g. there is
> no 
> point in explicitly fetching bundles anymore). It is also lacking 
> business rules describing how to handle the issues I raised above.
> 

See above.

> In theory, this change does eliminate contention on the devicelist. 
> Currently, announcing a device requires updating the devicelist to
> add 
> the new device, while retaining all old ones in the same item 
> ("read-update-write"), so there might be a situation where devices 
> overwrite one another if they both attempt to announce themselves at
> the 
> same time. But this really isn't as big of an issue as it may seem
> at 
> first. First of all, the odds of this happening are very slim.
> Devices 
> are not created anew or removed entirely very often in regular use.
> 
> There's also a really simple fix for this in the current XEP
> already: