Notices by Yuri Volkov (yvolk@loadaverage.org)
-
Yuri Volkov (yvolk@loadaverage.org)'s status on Wednesday, 20-Mar-2019 05:25:59 UTC Yuri Volkov Morning in Moscow, sun reflecting in a wet asphalt https://loadaverage.org/attachment/5107243 -
Yuri Volkov (yvolk@loadaverage.org)'s status on Thursday, 21-Feb-2019 18:33:46 UTC Yuri Volkov @emacsen I mentioned WebFingerId not as a part of WebFinger protocol, but only as an artificially created identifier, helping to figure out the same actors via old-style (Twitter-like...) client APIs (which don't provide globally unique identifiers of actors (users...)).
As we're currently are figuring out, how to use #ActivityPub C2S protocol in the real world :-) I see that WebfingerId isn't really needed in ActivityPub API: Actor's profile has enough information to know both username and hostname of an actor (what constitutes WebFingerId).
I think that you will be interested to read our discussion on this here: https://github.com/andstatus/andstatus/issues/499
@cwebber @thefaico @eliotberriot -
Yuri Volkov (yvolk@loadaverage.org)'s status on Saturday, 27-Oct-2018 13:25:54 UTC Yuri Volkov Note - Client to server #ActivityPub layer for #Pump.io ?!
@alex@pump.strugee.net @evan@identi.ca Hello pals!
Looking at the Pump.io's GitHub site https://github.com/pump-io/pump.io I see some discussions regarding #ActivityPub support, but I couldn't figure out if you are implementing client to server layer of #ActivityPub ?!
If yes, what's the status of this work?
I want to make #AndStatus Android app an ActivityPub client, but I need at least one server that supports this in order to test my implementation, naturally :-)
--
yvolk@identi.ca
URL: https://identi.ca/yvolk/note/ab2wuiDPTYOQBjupeSmYRA -
Yuri Volkov (yvolk@loadaverage.org)'s status on Tuesday, 29-May-2018 05:47:44 UTC Yuri Volkov After a long break I tried Profiler in Android Studio looking for a way to optimize performance of #AndStatus. And now it not only works, but allows me, at least on #Android emulator, to see most lengthy operations. As a result, a timeline loads at least three times faster. To be released in AndStatus v.39.
Profiler allows you to record your application's activity and present it as "Call chart", where you can see durations of execution for each method in the stack and easily figure out most lengthy.
Clicking on the method's bar in this call chart brings you to its source code...
I found out that Regex-related methods are the most time-consuming, and optimized them both via using compiled Pattern instead of regex strings, and by executing lengthy operations once only (i.e. I store result of such checks and reuse it later instead of repeating costly operations).
Doc on the #AndroidProfiler : https://developer.android.com/studio/profile/ https://loadaverage.org/attachment/4309407 -
Yuri Volkov (yvolk@loadaverage.org)'s status on Sunday, 13-May-2018 16:20:52 UTC Yuri Volkov @jaller94 Thank you very much for the contribution. The https://github.com/fastlane/fastlane really looks like a unifying way to store metadata for both F-Droid and Google Play, both of which #AndStatus uses.
I was especially impressed by the tool's (advertized...) feature "fastlane supply init: download metadata for an existing app to a local directory", which I understand as ability to initialize metadata with what is already stored in Play Store...
As you may know, AndStatus already has quite a lot of screenshots in Google Play Store https://play.google.com/store/apps/details?id=org.andstatus.app plus several (duplicating them...) - in AndStatus Wiki repository, see: https://github.com/andstatus/andstatus/wiki
It would be good to synchronize them, store in a single location and make available for all usages.
This is why I think that I should start with importing existing images / metadata from Google Play Store, and only after that update that images (if necessary) with your contributed screenshots.
?! -
Yuri Volkov (yvolk@loadaverage.org)'s status on Tuesday, 17-Oct-2017 05:46:12 UTC Yuri Volkov @jark Reviewing and improving #ActivityPub specification is not about coding/programming. It's about analysis and modeling. But my experience shows that it's hard to notice problems and mistakes in such documents, until you don't try to start actually using it in practise, in this case - starting to implement some application using this specification OR starting to adapt this specification, as an Analyst, for some concrete application. This way you will read every phrase, some of them - many times...
@mike @verius @clacke @cwebber -
Yuri Volkov (yvolk@loadaverage.org)'s status on Thursday, 12-Oct-2017 06:57:54 UTC Yuri Volkov @cwebber@octodon.social Thank you for reply to the #ActivityPub issue at https://github.com/w3c/activitypub/issues/260
I followed the discussion there plus copying my follow-up below:
1. Let's go step by step. Explicitly stating that Actors and Users are different entities is a good way forward.
BTW the confusing phrase "users are represented as "actors" here" should also be changed to "users are mapped to actors" with addition, how (you suggested wording...)
Where can we see current draft for review how it looks now? You are too quick to state that the issue is resolved :-)
2. Let's check if the statement is valid:
* ""user" is technically an entity outside the protocol"
2.1 First of all the term is used tens times in the document, which describes the protocol: https://www.w3.org/TR/activitypub/
2.2. The term "user" is used for two different things, actually:
* for "natural person from a real world"
* and for "user's account at a Servetr" (my interpretation).
The second meaning is definitely "inside protocol". Just look at these phrases, from many available, for example:
* "This protocol permits a client to act on behalf of a user."
* "Client to server interaction takes place through clients posting Activities to a user's outbox"
My conclusion is that a User in the second meaning "user's account at a Server" is definitely a part of the protocol description.
3. As now we agreed on separation of an Actor from a User, let's look again, what we read in the document.
3.1 You know: there are many places, where the word user(s) should be replaced with a word Actor(s), e.g. here {again, one of many examples):
* "The Follow activity is used to subscribe to the activities of another user."
Attributes of a User are presented as attributes of an Actor in examples... -
Yuri Volkov (yvolk@loadaverage.org)'s status on Monday, 09-Oct-2017 05:48:29 UTC Yuri Volkov @mike@macgirvin.com I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in pump.io. Confusion of Actors and Users of servers in the #ActivityPub I regard as a conceptual mistake that should be fixed _now_. So I proposed concrete additions to the spec in this issue: https://github.com/w3c/activitypub/issues/260
Not many responses so far :-( -
Yuri Volkov (yvolk@loadaverage.org)'s status on Sunday, 01-Oct-2017 05:04:45 UTC Yuri Volkov I filed a bug for #ActivityPub, which is exactly about Person's freedom to choose (and actually, change) an instance/server of a global social network without loosing his/her identity, including historical data.
Moving from one instance of a federation to another is a normal case, just like having user accounts at several servers. And #ActivityPub specification should explicitly allow this.
See https://github.com/w3c/activitypub/issues/260
@fuzboleroxv @citizenphnix
@cwebber @gargron @deadsuperhero @mmn @lnxw48a1 -
Yuri Volkov (yvolk@loadaverage.org)'s status on Friday, 29-Sep-2017 06:00:09 UTC Yuri Volkov @cwebber Reposting to make sure you received my reply. Where should I file this #ActivityPub issue?
The #ActivityPub spec's problem is not in that simplistic phrase "users are represented as actors here".
The problem is that there is NO technical description of the whole domain model layer: relation between Actors (e.g. Person) and Users of servers. Current version will be interpreted as having one-to-one relation between the two _different_ kinds of entities, and that _is_ incorrect
?!
My first post on this subject was:
Contemplating on correct implementation of a data model, corresponding to the #ActivityPub specification, I started to realize that current version of the document https://www.w3.org/TR/activitypub has a gap/confusion of two different notions: Person (one of Actor types, see https://www.w3.org/TR/activitystreams-vocabulary/#dfn-person ) and a User of a server (quote from ActivityPub spec: "users are represented as "actors" here")
Actually these are very different notions: a Person may be represented as more than one User, on different servers. And a User may represent not a Person, but e.g. an Organization.
?!
@clacke -
Yuri Volkov (yvolk@loadaverage.org)'s status on Tuesday, 15-Aug-2017 05:28:33 UTC Yuri Volkov Suggested correction to https://www.w3.org/TR/activitypub/
1. I noticed an inaccuracy in section 6.9. "Undo Activity"
"The undo activity and the activity being undone must both have the same author."
"author" should be changed to "actor" here so it will read:
"The undo activity and the activity being undone must both have the same actor."
2. Actually, the "author" property is used (informally ?!) in examples of this document, but I didn't find _any_ reference to such a "property" in https://www.w3.org/TR/activitystreams-vocabulary/
the latter documents uses "actor" instead.
Looks like autor should be replaced with "actor" in examples also to avoid confusion and incompatible implementations...
?! -
Yuri Volkov (yvolk@loadaverage.org)'s status on Sunday, 14-May-2017 07:32:14 UTC Yuri Volkov Yesterday I was implementing #Mastodon API in #AndStatus. Comparing AndStatus with #Tusky client at some point I noticed that Tusky shows me a new post, which mentions myself. But I couldn't find the same post in any timeline that AndStatus feeds from the Mastodon server.
It appeared that in addition to Twitter/GNU Social-like timelines Mastodon has something conceptually similar to an "Activity stream" that is called "Notifications" here and, as other parts of the API, is "hand made" :-)
Actually, this is a good sign, showing that ideas of #ActivityStreams (currently represented by the #ActivityPub standard https://www.w3.org/TR/activitypub/ ) are growing in the heads of the Mastodon developers. I would go one step further and formulate all timelines and actions as activities and activity streams...
It's interesting that these ideas are growing in _my_ head also :-) - I decided that internal AndStatus model of notifications will be based on ActivityStreams too. I.e. each individual notification will have an Actor, an Action and an Object/Content e.g. "Peter posted 'I met a friend'". Having notifications in such a structure, we will be able to show them to a User in any needed form: in the Android Notification bar or as a timeline.
Currently AndStatus shows mostly "mentions" only in its "Mentions" timeline... -
Yuri Volkov (yvolk@loadaverage.org)'s status on Saturday, 13-May-2017 09:30:29 UTC Yuri Volkov @perspicacious01 As I understand, full text search would require much more resources than a simple hashtag indexing. On the other hand, knowing that hashtags are searchable, allows to write messages with predictable #discoverability. I mean that adding a known hashtag to a message will ensure that the message will be present in the "Hashtag timeline".
BTW in #AndStatus such "Hashtag timelines" (like other Search timelines) are the "first class timelines". I.e. you can sync and use them exactly like e.g. Home Timeline. -
Yuri Volkov (yvolk@loadaverage.org)'s status on Wednesday, 26-Apr-2017 05:52:12 UTC Yuri Volkov @wakest Most important features of Mastodon support are implemented in AndStatus, but I need some more checks and additions before Beta release. Especially regarding image attachment...
Current state is reflected at the bottom of this ticket:
https://github.com/andstatus/andstatus/issues/419 -
Yuri Volkov (yvolk@loadaverage.org)'s status on Tuesday, 28-Mar-2017 04:45:47 UTC Yuri Volkov In order to make "Days from today" column look better, I right-aligned numbers in that column https://loadaverage.org/attachment/3514860 -
Yuri Volkov (yvolk@loadaverage.org)'s status on Monday, 27-Mar-2017 05:26:55 UTC Yuri Volkov Calendar Widget for Android got a new compact and clear "Single line" layout, see the screenshots https://github.com/plusonelabs/calendar-widget/issues/42#issuecomment-289261236
To be honest, I dreamed about something like this since the first day I joined this Open Source project two years ago :-) Looking at what this layout brings to us, I don't understand, why I didn't do this earlier. Probably I thought that addition of an alternative layout would be a too hard task for me... but it took a working day only.
This is only one of several recent improvements of the Calendar Widget, available at Google Play and f-droid. These changes are not released yet, but as a Source code is freely available, you can start playing with them right now https://github.com/plusonelabs/calendar-widget -
Yuri Volkov (yvolk@loadaverage.org)'s status on Monday, 24-Oct-2016 18:15:30 UTC Yuri Volkov I'm beginning to rediscover Pump.io
After the report https://github.com/andstatus/andstatus/issues/425 by clacke@microca.st I realised that due to some error in identi.ca I stopped receiving messages from the people, that I follow, at least 6 months ago. Instead, I was receiving messages by some other person, whom I didn't follow (the same in my Timeline of AndStatus and at the identi.ca web site).
After re-following all of my Friends, I started to get something interesting, at last. Although not many new posts are created on Monday :-)
And you know, I received two posts from another unknown person :-)
This time I decided to figure out, why I see these posts and it appeared that these posts were "favorited" by one of my friends. AndStatus, unfortunately, doesn't show me this reason like it shows "shared" (reblogged/retweeted) posts. And it came to me that AndStatus really needs to show that the post is shown, because it is "liked/favorited". The same way as reblogs are shown, only starting with the "heart" 💛 icon. ?!
--
yvolk@identi.ca
URL: https://identi.ca/yvolk/note/LSYanK2vTlGiwSuem4eF9Q