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.
> >>
> >>
On 04.03.2018 17:02, Peter Saint-Andre wrote:
> On 3/4/18 1:27 AM, Florian Schmaus wrote:
>> On 04.03.2018 02:30, Peter Saint-Andre wrote:
On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin wrote:
Thanks for the answers. I'm fine for the 3071 limitation, so we can set it
See my answer to Mathew, maybe i clarified better. cu
On Sun, Mar 4, 2018 at 9:08 PM, Philipp Hörist wrote:
>
> 2018-03-04 18:37 GMT+01:00 Lazar Otasevic :
>
>> Phillip,
>>
>> I feel like we dont entirely understand each other. Are you sure you did
>>
>
>
> > Matthew,
>
> I really don't understand this argument. Doing a MAM query is exactly
> like fetching a list of ids, except that you also get the content as
> well. As I mentioned, I see no case in which you would want the ids
> and not the content. Even if you get the ids, you will fetch the
On 4 March 2018 at 17:30, Lazar Otasevic wrote:
> Matthew,
>
> I may be repeating: every efficient sync algorithm needs iterating trough
> ids and content separately. Of course we may make sync work without
> iterating trough ids, but implementations like that are just
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
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
On Sonntag, 4. März 2018 10:29:02 CET Gerion Entrup wrote:
> Hi,
>
> I'm a user of XMPP and have very mixed experiences with different clients.
>
> There are clients that do very well and implement a lot of availabe XEPs,
> but other clients only implement a fraction of available XEPs. The XEPs
Phillip,
I feel like we dont entirely understand each other. Are you sure you did
read and understood my post?
Getting array of ids gives you the order because ids should come in the
order respective messages are archived, and getting content is an extra
step above, unrelated to order. Content
On Samstag, 3. März 2018 23:53:21 CET Lazar Otasevic wrote:
> Hi, I think I miss some features here:
>
> 1. fetching messages by giving a set of ids, also similar like xep-013
>
> Fetching message by id(s) is needed for example when i have a custom push
> notification with a given message id(s)
Matthew,
I may be repeating: every efficient sync algorithm needs iterating trough
ids and content separately. Of course we may make sync work without
iterating trough ids, but implementations like that are just terrible, too
complex, too coupled with the rest of design and not optimal.
I agree
Version 0.2.0 of XEP-0401 (Easy User Onboarding) has been released.
Abstract:
This document defines a protocol and URI scheme for user invitation in
order to allow a third party to register on a server. The goal of this
is to make onboarding for XMPP IM newcomers as easy as possible.
Changelog:
On 3/4/18 1:27 AM, Florian Schmaus wrote:
> On 04.03.2018 02:30, Peter Saint-Andre wrote:
>>> On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin wrote:
>>> Hi,
>>>
>>> Thanks for the answers. I'm fine for the 3071 limitation, so we can set it
>>> both for the Pubsub nodes id and
Hi Lazar,
On 3 Mar 2018 22:54, "Lazar Otasevic" wrote:
>
> Hi, I think I miss some features here:
>
> 1. fetching messages by giving a set of ids, also similar like xep-013
>
> Fetching message by id(s) is needed for example when i have a custom
push notification with a
Hi,
I'm a user of XMPP and have very mixed experiences with different clients.
There are clients that do very well and implement a lot of availabe XEPs, but
other clients only implement a fraction of available XEPs. The XEPs are
optional, if I get it right, but the user experience varies a lot
Hi,
If you use MAM like that you will run into problems.
if you request a specific ID you lose the Order information inside the
Archive.
your only option is to use the timestamp for ordering, but many messages
can have the same timestamp.
XEP:
These IDs are strings that servers may construct in
On 04.03.2018 02:30, Peter Saint-Andre wrote:
>> On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin wrote:
>> 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
17 matches
Mail list logo