Smithereen also implements NodeInfo
(partially — I don’t keep track of account activity, at least not yet)
However. The concept of posts and comments fits my presentation nicely because I have both and they are very distinct in the UI, but what if there are different kinds of content? For example, what if I add photo albums? How would I count these and photos within, or would I ignore them entirely? The idea of “kind, count” pairs does indeed feel like the way to go.
Thanks @grishka, I’ll update the FEP to add Smithereen – an oversight on my part (sorry!). Hopefully the bullet in the FEP that reads…
localCommentsare not denormalized into pairs of
(kind, counts)for software that, for example, hosts audio files, hosts videos, or software that does not have comments, or does not have posts.
…captures your comments around photo albums. You’re correct that ideas like
(kind, count) I’m trying to not be too technically prescriptive/dictatorial in solutions, just give a general sense of what alternatives could look like. I can update the FEP to make that clearer.
Additionally, Mike provided the following feedback to me here:
- Providing the version should never be mandatory (this is potentially a critical security issue).
- Count of “users” should likewise not be mandatory, and if it is, the concept needs to be better defined.
In my projects, a single user can be the controlling party behind an unlimited number of communication channels which may or may not be related. The same account registrant can also create groups and “collections” (aka sub-channels). They can also clone any of these communication channels to multiple servers. It isn’t always obvious what percentage of that user’s overall activity was actually carried out on a different website. Should they be able to claim this as some percentage of a single user’s activity? If not, the counts will be wrong. Either one site will claim 100% of the user and the others will have to remove that user from their own tallies (resulting in a fictional total for any of these sites), or they will each claim 1 user and the tallies will likewise be fictional.
I’m inclined to disagree on the first bullet, but fully agree on the rest.
My disagreement on the first bullet rests on the assumption that the “critical security issue” is disclosing of a software version number that identifies software as having a vulnerability (that may be patched at a later version). Simply removing the version number is obscuring the problem, not solving it, and is security-by-obscurity. Adversaries will simply try the exploit on a server that hasn’t disclosed a version anyway, and I would argue now non-malicious users and developers alike would have less information available to themselves to identify how many servers are still vulnerable, and contact admins to upgrade ASAP. Which is a net detriment, in my opinion.
As such, I’d like to avoid putting the first bullet in the FEP.
Mike’s second bullet and elaboration I agree with and would like to modify the FEP to include.
To update: I agree with Mike that
software.version should not be a required field. It is unnecessarily strict. I just was hoping to avoid citing “potential security issue” as the specific reason. I don’t feel that strongly about it as others, so I’ve gone ahead and included it with that specific rationale.
software.version is required as a way to ensure compatiblity. If it could be replaced with some protocol or API version, it might alleviate the security issue, i.e., by telling machines : expect this API, instead of telling attackers: I’m running that vulnerable version. Since AP has a stable version, indeed, this field is currently unnecessary in AP context.
And this is how we come to the need to have some sort of capability negotiation between servers
Imagine people hardcoding checks for software names and versions. This can’t end well.