Notices by AndStatus (andstatus@loadaverage.org), page 28
-
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 19:20:44 UTC
AndStatus
@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 -
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 Sunday, 27-Nov-2016 07:29:42 UTC
AndStatus
#AndStatus v.30.04 (198) published to the Open Beta testing channel https://play.google.com/apps/testing/org.andstatus.app
Translations updated thanks to volunteer translators! (see https://crowdin.com/project/andstatus )
All known crashes fixed. Thank you for your crash reports!
In particular, we found a cause of intermittent application freezes for a second or two: loading and saving of the commands queue. Now this is done asynchronously. -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 17:32:35 UTC
AndStatus
@dtluna @lnxw48 For those, who don't like Github for some reason, I imported #AndStatus repository to Gitlab. URL differs from Github in two letters only: https://gitlab.com/andstatus/andstatus/
Is this ok?
@d0e @lambadalambda @dt -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 15:15:11 UTC
AndStatus
@dtluna Would you help the project, if I create alternative AndStatus repository at a git hosting of your choice?
@d0e @lambadalambda @lnxw48 @dt -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 15:00:16 UTC
AndStatus
@dtluna I don't believe hosting at Github is a stopper for anyone, who really wants to contribute a source code :-)
@d0e @lambadalambda @lnxw48 @dt -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 14:34:06 UTC
AndStatus
@lnxw48 Anyway, if anybody wants to improve AndStatus to have OAuth for !gnusocial, you are welcome at https://github.com/andstatus/andstatus/
@d0e @lambadalambda @dtluna -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 14:26:42 UTC
AndStatus
@lnxw48 Maybe that time I didn't figure out how to get Client keys... -
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 12:30:27 UTC
AndStatus
@lambadalambda When I tried to implement OAuth for GNU Social some years ago... I couldn't and I didn't find any working implementation example.
BTW recently we implemented OAuth2 for Mastodon in AndStatus. Didn't agree on the other API though yet...
@d0e @dtluna
All Chirp! content and data are available under the