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

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

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

On 18 March 2018 at 21:59, Sebastian Riese wrote: > On 18.03.2018 21:30, Guus der Kinderen wrote: >> On 18 March 2018 at 18:56, Jonas Wielicki wrote: >> >>> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: Having implemented 0048

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

Hi to all, On 18.03.2018 21:30, Guus der Kinderen wrote: > On 18 March 2018 at 18:56, Jonas Wielicki wrote: > >> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: >>> Having implemented 0048 via 0223 earlier this week, I can only applaud an >>> effort of

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

On 18 March 2018 at 18:56, Jonas Wielicki wrote: > On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: > > Having implemented 0048 via 0223 earlier this week, I can only applaud an > > effort of making the documentation easier to digest. Thanks for this! > > > >

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

Sun, 18 Mar 2018 21:17:16 +0100 Philipp Hörist wrote: > If you want to work on MUC, there are a hundred threads about the > upcoming MIX standard. I hope this will never become an adopted standard. ___ Standards mailing list Info:

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

2018-03-18 19:47 GMT+01:00 Ненахов Андрей : > If the only reason to have bookmarks is to store there information about > conference rooms, can we instead concentrate on better MUC standard that > does not rely on various crutches like bookmarks to work properly

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

If the only reason to have bookmarks is to store there information about conference rooms, can we instead concentrate on better MUC standard that does not rely on various crutches like bookmarks to work properly across connected clients? On 18 Mar 2018 18:36, "Jonas Wielicki"

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

Sun, 18 Mar 2018 18:56:48 +0100 Jonas Wielicki wrote: > Two or more clients updating different bookmarks at the same time (or > maybe at different times, but one had a network outage inbetween and > can only actually perform the update at a later time). Currently, it >

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

On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: > Having implemented 0048 via 0223 earlier this week, I can only applaud an > effort of making the documentation easier to digest. Thanks for this! > > I am, however not sold on the idea of having a bookmark-per-item: what > problem

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

Having implemented 0048 via 0223 earlier this week, I can only applaud an effort of making the documentation easier to digest. Thanks for this! I am, however not sold on the idea of having a bookmark-per-item: what problem is that solving, or what benefit does this give us? I appreciate how it

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

Looks great, thanks Dave and JC! The only feedback I'd like to give is that the password field should be removed. If use of the password field is not recommended, why have it? It seems perfectly fine to say that you can't autojoin password protected MUCs without a prompt or that individual

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

On 18 March 2018 at 14:07, Daniel Gultsch wrote: > Hi > > I would like to see a disco feature for the compat mode (4.2). > This way I as a client developer know when it is safe to store > bookmarks using this method and this method only without loosing > legacy clients. >

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

Hi I would like to see a disco feature for the compat mode (4.2). This way I as a client developer know when it is safe to store bookmarks using this method and this method only without loosing legacy clients. Furthermore we'd have something the Compliance Tester can pick up on. While I see that

[Standards] UPDATED: XEP-0045 (Multi-User Chat)

Version 1.31.1 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to

[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Version 0.9.6 of XEP-0369 (Mediated Information eXchange (MIX)) has been released. Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide

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

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

[Standards] UPDATED: XEP-0163 (Personal Eventing Protocol)

Version 1.2.1 of XEP-0163 (Personal Eventing Protocol) has been released. Abstract: This specification defines semantics for using the XMPP publish- subscribe protocol to broadcast state change events associated with an instant messaging and presence account. This profile of pubsub therefore

[Standards] UPDATED: XEP-0107 (User Mood)

Version 1.2.1 of XEP-0107 (User Mood) has been released. Abstract: This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angy, or annoyed. The payload format is typically transported using the personal

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On Samstag, 17. März 2018 21:33:54 CET Tedd Sterr wrote: > I didn't expect this to turn into a drawn-out argument; I merely suggested a > simple solution to something that could otherwise be seen as a problem. Nor > am I continuing it for my own amusement, but I genuinely don't understand > why

[Standards] Bookmarks 2 : Age of Ultron

Folks, Jan-Carel Brand and I were idly discussing how complicated the interplay was between XEP-0048 1.0 (Historical/Active - single storage element, multiple bookmarks), XEP-0048 1.1 (Standards Track/Draft - single item, multiple bookmarks), XEP-0049 (multiple storage elements), and XEP-0223