XSF Discussion - 2017-10-09

> prime audience for the use of end to end encryption (drug addicts) [...] Sad how scared of authorities he seems to be :(

I think in russia it’s a bit healthy to be scared of authorities......

in western countries too, tbh

mathieui, I think there it’s healthy to have respect of authorities. Scared is another level.

well, not "scared", but "expecting the worse of them at all times"

Is there a way to retrieve all newer PubSub items after the item with ID X?

Flow, with RSM possibly

Result Set Management, it’s a XEP

apparently some pubsub services support that

I don't found anything in xep59, xep60 and xep313

wouldn’t you give the item ID as minimum and then query everything after that?

RSM appears to be more about "paging through the resulting set"

not about that particular query

it is not necessarly clear that the RSM IDs are the same as PubSub item IDs.

yeah

I’ve seen them differing, too

I think that's what https://xmpp.org/extensions/xep-0313.html#sect-idm139955456388768 was for

MAM ids != PubSub item IDs. If only because those are not guaranteed to be unique.

too many IDs ;/

Flow: that's what I said, recently.

Flow: https://xmpp.org/extensions/xep-0312.html

Flow: but you didn't like it :(

Ge0rG: out of context

Flow: Not sure (where) that's implemented, though.

On any given service, only (node id, item id) needs to uniquely point to an item. But you can republish an item with the same ID, which would defeat the purpose of the id in MAM.

Flow: "too many IDs" is true irregardless of context.

Flow: Ah nonsense, that only works with a timestamp.

So there is no way to catch up on pubsub items while offline, presuambly because the assumption is that you will get the notifications about new items also while offline?

Hmm well 0312 does somewhat try to provide that, no?

I really start to dislike xep0060. Not only is there no way to reliable get the publisher's JID, you also can't do the simplest queries…

That's why someone at the Summit was suggesting using 313 for 60 queries.

goffi's PubSub component does MAM, I think.

jonasw, If I want to make changes to JET, shall I make these changes in xep-0391, or inbox/jet?

vanitasvitae: inbox/jet should cease to be a thing as soon as it's got a number

okay :)

Ge0rG, no, it still exists for historical purposes

vanitasvitae, updates against xep-0391.xml

maybe we could get rid of that, we've got git history after all.

Ge0rG, I think the purpose is to have it on the webserver too

jonasw, I noticed, that the XEP mentions a dependency on 234 (jingle file transfer). Is this necessary? JET should work for other Jingle usecases too, even when a client does not implement 234.

Looks like I added that dependency, when the document was still titled "Jingle Encrypted Transfers"

vanitasvitae, I didn’t add that depedency :)

feel free to modify that

okay

in Experimental, you can do basically everything as author ✏

you just need to preserve compatibility

okay. I should also add revisions, right?

vanitasvitae, you SHOULD, yes. An editor will do that if you don’t.

when you do it, you have the chance to make the revision text as meaningful as possible :)

:D I'll do you the favor :)

if you would follow the spirit of semantic versioning when choosing the next version number, that’d be great

So MAM with PubSub only improvement are the query conditions 'start', 'end' and 'with'. But we could specify a PubSub specific (after|before)-pubsub-item-id?

Does mam+pubsub mean mam-rsm ids are pubsub ids or?

Zash: intosi says no

Altho with pubsub ids being user-controlled ... and sometimes always "current", glhf

For the same reason I had to invent a new "value" for the "Atomically Compare-And-Publish PubSub Items" XEP

(Of course the reasoning is not false, I just think that it is a design flaw that IDs may point to different content, instead of having an <item-retracted/> marker)

Zash "always "current""?

Flow, maybe you could first specify your new ID for re-use by different things and then build CAP on top of that?

jonasw: I'm not sure if it's of any use

Flow: In a bunch of PEP things, the item ID is always the string "current"

besides of the compare-and-publish case

this https://xmpp.org/extensions/xep-0060.html#impl-singleton

Zash: indeed. And just the fact that the Item ID is something the publisher can provide, instead of letting the server guarantee its uniqueness across the service, is enough to invalidate it for MAM id.

Yeah

Like with message@id

Hm, does that mean thaw MAM+PubSub is doomed?

Zash: You can still use 'start', 'end' and 'with'

Yes

And specify further fields for MAM+PubSub like after-pubsub-item-id

Does the pubsub service have final say over the item id?

MAM with Pubsub has semantics that differ from Pubsub retrieval anyway, as you're likely to get the same itemid more than once in some use cases.

I was never convinced about MAM+pubsub

MattJ: Weren't you the one who said "Just use MAM?" back then?

niirc :)

I REMEMBER EVERYTHING .. almost

I use MAM instead of remembering everything.

I use a server-side client with logging.

^

MAM is too bumpy.

Or you can just forget everything the instant it scrolls off the screen. If it was important then they shouldn't have written it over an ephemeral instant messaging thing! :)

...

we can change the 0060

it's not like we have many Pubsub + MAM implementation in the wild :p

are there any impacts of MAM?

Impacts?