Conversation
Notices
-
@maiyannah My main wish for GNU Social API improvement is to have URIs (globally unique identifiers) of users and messages everywhere, where now ”local" IDs are used. I see local ids usage as a major deficiency of current API. Which breaks federation (from a client point of view) and provides a small window - one "instance" of the network, via which the whole communication occurs.
Moreover, I would suggest not to reinvent a wheel and lookup current API of Pump.io - implementation of ActivityStreams v.1. BTW, It's version 2.0 is currently a Recommendation draft of W3C https://www.w3.org/TR/activitystreams-core/
@archaeme
-
@maiyannah I think that "namespaced by instance" is OK.
E.g. user ID: acct:andstatus@loadaverage.org
message ID: msg:208167@loadaverage.org
The main point is that in order to request the same user or a message from different GNU Social instances, one should use the same Global ID.
I.e. the same URL path will be used to request same message from any instance, e.g.:
/statuses/show/msg:208167@loadaverage.org
- for ANY instance, not for loadaverage.org host only.
Plus such URIs allow to find out a source of the URI very easy...
@takeshitakenji @archaeme
-
@maiyannah 1. I agree, adding new field into each "object" of the JSON message with UID in addition to each existing ID will be a good compromise preserving compatibility with old clients.
2. Regarding choice of the UID format/structure I strongly support a UID, which allows to identify easily the GNU Social instance that generated the UID. This way clients will be able to request, if necessary, additional information from the "Golden source". E.g. seeing the conversation ID:
"msg:208237@loadaverage.org" a client can automatically figure out that:
* this is GUID of a message/notice
* the message has this local Id (used by old clients and old !gnusocial instances): 208237 - a client may even query that instance for this local id (useful e.g. for conversations IDs... if new API is not supported by the instance...)
* the host/instance that created this message, is: loadaverage. org
No "hashes" as UIDs, please. Meaningless hashes will not allow to discover a !fediverse
?!
-
@maiyannah Thank you, I will definitely take part in discussions and in remote testing using AndStatus client. But currently I don't plan to setup my own server.
My personal email: yvolk1@gmail.com
-
@verius Local IDs (long numbers) may or even should be used internally to simplify local database design and improve performance. URIs are for data exchange via APIs ?!
E.g. in AndStatus we use numbers (local ids) as keys for relations between tables...
@maiyannah
-
@maiyannah 1. As we are thinking about good interoperability with !gnusocial instances that have old API only, I think we better add "local I'd part" not only to the newly formed "message/notice id", but to other IDs also.
So a User UID will be: acct:andstatus@loadaverage.org:5263
i.e. it will include local user I'd as the third part of the UID
2. Regarding message/notice IDs I see that currently e.g. via loadaverage.org I already see the "uri" field in JSON responds, e.g.:
"uri": "tag:loadaverage.org,2016-12-03:noticeId=8986502:objectType=comment",
or via quitter.no:
"uri": "tag:gnusocial.club,2016-12-04:noticeId=193512:objectType=note",
The uri has all required parts to allow descoverability. I don't if this field is part of the mainstream GNU Social code though...
3. Conversation IDs should have their own namespace, e.g.:
cnv:12345@someserver.org
- as you see, it also explicitly includes local conversation ID, meaning that the conversation could be requested from the "source” host, if needed. I expect that taking into account that messages of the same conversation may be created at hosts with old API only, in practice we will have different ”conversation_uri" values in different messages of the same logical conversation. I think that originally created message should not be modified in any case, so we will have the same data no matter from which host/instance we received it.
?!
@archaeme @verius @mmn
-
@maiyannah Regarding unique Message IDs and global messages' identification/matching/reduplication.
It came to me that the root of messages duplication problem that we are periodically discussing, lies in the message ID generation at a server side. This is why messages, which were not posted yet from a client to a server, cannot be easily identified: they have to be matched both by a Sender and by their body. This causes, in particular, duplicated messages.
I think that as we are discussing new client-server API, we should improve this also: Globally unique message ID should be generated at its actual creation point: in a client application (whether it is a Web client or a mobile device client...)
This means that Message UID should include not GNU Social instance UID, but a User account UID AND User device ID - the latter has not to beglobally unique:
User's Device - unique for this Account.
My account UID at loadaverage could be "acct:andstatus@loadaverage.org:5263" (see my previous post)
Thus, messages, posted from my "andstatus" account using mobile device "d1" will be automatically assigned (by that "d1" device) such IDs:
msg:17625@d1@andstatus@loadaverage.org:5263
The first number "176625" is local ID of the Client, which created this message
next device ID goes: "d1"
and the full User UID is appended (without "acct:")
As you can see, in this my message UID proposal "local ID of this GNU Social instance" is not included in the message UID. This allows both a Client and a server identify duplicated posts easily AND interpret repeated sending of a message with the same UID as e.g. a change/editing of the message (if a server supports such an action) or simply ignore the duplicate.
Main point of this post are parts, comprising the Message ID, and a point of its creation. Not the exact format of the UID.
?!
@archaeme @verius @mmn
-
@andstatus the URI (as in the context of Atom post id, which !GNUsocial uses as a transport format) cannot be assumed to have a discernible structure. It can be any character combination, or at least only as restricted as in the Atom standard.
The URI is available in the post's raw atom formatted representation. It is probably still not available in the Twitter compatible API because it was never designed for federation. I don't believe I have ever recommended anybody to use the Twitter compatible API because of its limitations.
-
@mmn No problem with "opaque" URIs. They simply won't be parsed and hence will be useless for discovery of the !fediverse. Old clients/servers won't parse any URIs anyway.
Actually we are discussing future client API for GNU Social that @maiyannah is planning to implement. I'm referring to Twitter-compatible API only for comparison.
@verius
-
@verius As @maiyannah explained, currently I'm proposing a new point of message UID/URI creation to help solving a problem of sending duplicated messages from a client to a server.
Message URI is exactly that field that can be universally used for deduplication in different cases. Including deduplication of messages that a client application received from different fediverse instances (using different accounts).
-
@maiyannah I would say that the best response to posting of a duplicated message will include that existing message object, which the new message duplicates. So the client app will know for sure that the message was successfully sent already and will have that sent message without additional requests.
@verius @thefaico
-
@verius Having a Message URI generated by a Client application allows to avoid any message body comparisons. For the case, when this is not an intentional duplication/spam. But spam is another topic, out of scope of this conversation.
@maiyannah
AndStatus
MMN-o ✅⃠
All Chirp! content and data are available under the