Notices by AndStatus (andstatus@loadaverage.org), page 26
-
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 10:50:43 UTC 
AndStatus
@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 (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 10:34:19 UTC
AndStatus
@takeshitakenji Implemented in AndStatus v.31.01: one existing "Reply to all” action is replaced with two, to avoid confusion: ”Reply to all conversation participants" (what we actually had before) and "Reply to all mentioned users”.
@theru @vinzv @archaeme@gs.archaeme.tech https://loadaverage.org/attachment/3357546 -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 10:23:39 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 10:06:53 UTC
AndStatus
@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). -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 09:45:57 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 17-Dec-2016 05:50:37 UTC
AndStatus
@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 (andstatus@loadaverage.org)'s status on Friday, 16-Dec-2016 20:09:59 UTC
AndStatus
@deavmi I agree, thank you for suggestion. Changed "Open on Internet" to "Open in browser" -
AndStatus (andstatus@loadaverage.org)'s status on Thursday, 15-Dec-2016 06:03:20 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Tuesday, 13-Dec-2016 18:59:50 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Tuesday, 13-Dec-2016 17:39:57 UTC
AndStatus
@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
?! -
AndStatus (andstatus@loadaverage.org)'s status on Tuesday, 13-Dec-2016 05:54:30 UTC
AndStatus
@maiyannah 1. Conversations also need Globally unique IDs. They are local numbers also now.
I'm currently testing usage of Conversation id to get full conversation in one request instead of "discovering" of previous posts one by one: and I'm really impressed by this feature of the API.
2. Another point of server load optimization: honoring since_id parameter in a search request. I created an issue for this bug several months ago: https://git.gnu.io/gnu/gnu-social/issues/206 ""since_id" parameter is ignored in a "search" request of Twitter-compatible API"
@mmn
@archaeme @takeshitakenji @xj9 -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 12-Dec-2016 21:11:05 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 12-Dec-2016 16:09:33 UTC
AndStatus
@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 -
AndStatus (andstatus@loadaverage.org)'s status on Thursday, 08-Dec-2016 16:00:55 UTC
AndStatus
@deavmi Please read on duplicated posts here: https://github.com/andstatus/andstatus/issues/83 -
AndStatus (andstatus@loadaverage.org)'s status on Thursday, 08-Dec-2016 10:12:25 UTC
AndStatus
@kevie
There is some problem in secure connection to the server. If cannot figure out the real cause, you can swith AndStatus to insecure SSL connection with this Social Network (goto Settings - > Accounts -> Manage Social Networks - > select this network and change "SSL Mode and security" setting...)
See for similar cases https://github.com/andstatus/andstatus/issues/208
@maiyannah -
Tristan B. Kildaire (deavmi@gnusocial.club)'s status on Wednesday, 07-Dec-2016 12:20:43 UTC 
Tristan B. Kildaire
@theru that's nice ti hear mate. I am happy now as my GNU Social instance that I am registered on allows.me to use #AndStatus which it previously didn't due to a problem caused by a bug in a plugin that has since been disabled. -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 07-Dec-2016 15:52:04 UTC
AndStatus
@tobi As you set this option at a server side, you should ask admin of your server, why it restricts posting... AndStatus is unaware of that option.
And please Share full error log from the "Commands in a Queue” in AndStatus + what you are exactly posting.
I can only guess that you replied to a user, who doesn't follow you (and thus confused server-side script...)
?! -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 05-Dec-2016 05:35:26 UTC
AndStatus
@zoowar What slowest "pace" of interactions are you expecting? I would say replying once in a year is a good sign of the subscription effectiveness. I mean that reading "news"/updates and staying quiet is better than artificial periodic replying with "OK" :-) in order to prolong the subscription
?! -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 03-Dec-2016 13:14:09 UTC
AndStatus
@zoowar Could you explain this?
"I so wish !gnusocial would drop subscriptions that have no local replies.” -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 03-Dec-2016 12:23:31 UTC
AndStatus
@juanbellas 180 is a position in the currently loaded timeline page (having 200 items on the time line opening). There may be more newer posts above than 180 messages.
AndStatus remembers your last timeline position in a similar way, this is why position on a page is close...
All Bobinas P4G content and data are available under the 