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 :
@jaller94 Thank you very much for the contribution. The 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 plus several (duplicating them...) - in AndStatus Wiki repository, see:
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.

Repost: The sad state of affairs in the social network and social forum world ..… Show more


The industrialisation of healthcare has made healthcare less about healing and more about treatment. The same thing can be said for the cybersecurity industry.

Just finished reading Thinking in Java Fourth Edition by Bruce Eckel published in 2006. Although the book describes the state of Java of more than ten years ago, it still contains many valuable observation, explanations and advices. Due to the book's age, it should be read with a caution, more as a philosophical and historical book than as a student's textbook.
Anyway I didn't find any new book comparable by its quality with this one. Amount of work and mind put in it shows.
Thank you, Bruce!

Revelation of the day: "Compare Tab With Editor" plugin for IntelliJ Idea solves a problem comparing files, located far from each other in the file tree, when it's hard to scroll from one file to be compared to another.
Now you can compare just two Editor tabs.

Currently I'm refactoring User-related part of #AndStatus data model using recent amendments of #ActivityPub specification, which I initiated: distinction between a User (a real life person or an organisation...), Accounts of this user in concrete instances (Servers) of the global social network, and an Actor - the entity, which is actually present in Activities of the ActivityPub protocol.
Very helpful clarifications, allowing me to express clearly relations between different things inside the application. For example, now I'm working towards creation of views on a User across all networks, logically merging Actors of this User.
As a result, at the first step you will see e.g. actions/messages by Actor as actions by ONE Actor, even if you see these actions via several Servers, e.g. via and via, as on the attached screenshot.
The next step will be to merge Actors of one User into one view. E.g. set and Actors as _one_ User. This cannot be done automatically due to current limitation of the #ActivityPub specification, but at least can be done manually for selected Users that you follow via their Actors in different networks...

"A general guideline is “Use inheritance to express differences in behavior, and fields to express variations in state.”"
Bruce Eckel

@verius @veg05 The issue we have is that Mastodon dominates ActivityPub and anything that project decides to do on a whim is being written and hardwired into ActivityPub policy and is driving the specifications. Most of these decisions are short-sighted decisions that only benefit Mastodon, but they affect and limit all future uses of ActivityPub to the lowest common denominator of what works best for Mastodon. So basically they're strangling and killing the protocol before it even has a chance to be a multi-platform communications tool. To be fair, ActivityPub started with a bucket load of problems and none of them have yet been solved in a meaningful way. The specification is weak where it matters and too restrictive where it doesn't matter. If you bring an ActivityPub implementation to the table as we've done, it doesn't matter that you've tried to allow it to federate with the rest of the metaverse and be a communications tool on a level playing field. Your implementation is measured only by how well it federates with Mastodon. The level playing field has already been destroyed. Another few weeks like this and we'll have to abandon ActivityPub for any other use than communicating with Mastodon. That will be its only purpose and it will be unsuited for anything else. I'm well aware of the different federation protocols currently in use. I've implemented Diaspora, OStatus, ActivityPub and invented DFRN (friendica) and zot (red/hubzilla) and for the most part found ways for all of them to co-exist.
Why one-to-one relation of Actor to Account is an edge case; from
Actor is actually User's virtual identity, their identifiable representative in a social network. Now please think about the Global Social Network ("federation of websites”), which is connected using #ActivityPub protocol.
How many different Actors would you use and how many Accounts?
I mostly use two different actors: "yvolk" as my personal Actor, and "#AndStatus” as my project's Actor. But I use (or used recently, so there is a history of my posts...) tens of Accounts to represent these two logical Actors at different Servers (websites). And I don't expect to switch to two Accounts for these two Actors any time soon. For many reasons... And as I see posts of other Users, they quite often use several Accounts e.g. for wider audience (different Servers have different audiences and different posts are visible from them...) and as a backup in a case of a server's outage or permanent shut down.
Due to limitation of most of existing Servers, each separate Account means a separate Actor (and ActivityPub copies this approach). But this is not what a User wants, when he or she creates the same ”MyCoolUserName" at different Servers. Ideally a User needs to decide if any new Account is for the same existing Actor or for a new one.
#ActivityPub currently not only doesn't give such an option. It confuses terminology and mixes User/Account/Actor notions so, that it's even impossible to express the need and clearly state current limitation of the protocol using terminology of this spec. But it will allow to clarify this using changes, resulted from this our discussion ;-)
And I see that a User who needs only one Account for his Actor, is usually a Newbie or someone, who doesn't use a Social Network actively. This is why I regard one-to-one Account to Actor relation as an edge case, not as a normal one.
More on fixing #ActivityPub spec from
I understand that making "data model" correct by separating concerns would mean changes in the protocol specification, and I can understand eagerness of people, preparing the spec for a long time, to release it, at last, even not perfect. This is why I think that the most important thing now is to communicate clear and correct domain model and terminology, opening a way for future protocol improvements.
This means that decision on whether or not to fix the data model now shouldn't be anchored with changes, related to resolution of this issue #260.
E.g. despite still having "inbox URL" inside Actor object in a "data model" we should describe the URL as Account's attribute...
I continue my discussion with a team, creating #ActivityPub specification, doing my best to solve its conceptual mistake of presenting Users of the real world, their Accounts at servers and Actors of #ActivityStreams as synonyms, see
From that discussion:
Account is not an Actor, it's an authorised communication channel, a way for an Actor to communicate in a Social Network using a Server... (more work on this phrase may be needed but the meaning is this). And this relation should be stated in the main part of the document, not in some "notes", exactly because this is a conceptual level statement, not an implementation intricacy...
At the edge case, which happens to be the only case currently covered by the ActivityPub spec, Actor relates to Account as one-to-one. And only for that edge case mixing attributes of Actor and of Account can be done, but only as a temporary hack, violating design patterns...
0 Thank you for reply to the #ActivityPub issue at
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:
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...
0 I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in 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:
Not many responses so far :-(
@zoowar This is exactly what I propose in this #ActivityPub specification bug report:
Separation of Actors (e.g. a Person) from Users of servers (user accounts) even on a conceptual (domain model level). Please support this fix!
@mike @cwebber

@FuzboleroXV 1. allows you to see messages from all Social Networks even in one timeline.
2. You can respond to a message as any of your accounts of _the same Social Network_.
For, accounts in all instances belong to the Single Social network. For Mastodon - only accounts on the same instance: because of outdated client API. More details +discussion with @Gargron here:

@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 has a gap/confusion of two different notions: Person (one of Actor types, see ) 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.
Show more

This page describes the instance - wondering what Mastodon is? Check out instead! In essence, Mastodon is a decentralized, open source social network. This is just one part of the network, run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!

Hero image by @b_cavello