When @Bubu created the Mastodon account for F-Droid, he also introduced me to the fediverse which instantly astonished me with these many servers federating together and creating this amazing community of people and software. Since then, I thought about how we can link F-Droid even more with it and wrote down my idea today: fdroidpub.
fdroidpub makes F-Droid repositories accessible on the fediverse by publishing events like new and updated packages as posts under packages’ accounts. By using the comments of packages’ latest posts on the website and in the client, this makes packages commentable and produces opt-in statistics about the popularity of an package with indicators like the amount of following users.
As the readme states, this is still only a rough idea and there isn’t any code yet. With this topic, I want to open a discussion about this idea and hear what other people think about it. You can also open an issue in the project’s issue tracker if you feel more comfortable with it.
If publishing a new release in fdroid-store triggers a toot: Does it makes sence to add the app change infos to the toot from change info if present (i.e. MyApp\fastlane\metadata\android\en-US\changelogs\4711.txt)
What would be the rule to shorten the info as a toot can only have 500 chars
should the toot url be added to the fdroid-client links?
i think what’s new entires are capped at 512 chars. But also instances can define theit own max toot length. It’s not a restriction of activity pub I think.
When tooting about android apps Chould/should we alredy use the proposed schema (i.e. toots about the transportr app contain “@de.grobox.liberario@pub.f-droid.org” ) , even if this proposal is not implemented yet?
No, I wouldn’t do this as it would lead to a lot of dead links as for now. Also, there isn’t currently anybody working on it so it could take a lot of time until it’s implemented. Thank you for your interest, though
From your description, it sounds like you want to implement the ActivityPub protocol from scratch. That would be a lot of effort, you could just run a Mastodon instance and use a script like this to use the API.
I would be interested in contributing, let me know if there is any programming i could help with.
Edit: I could also help hosting the Mastodon instance.
You’re right, I would like to see fdroidpub federate directly through ActivityPub and not proxied through Mastodon, as Mastodon is based on Ruby on Rails and therefore quite a overhead. Also, it’s healthier for the fediverse if there are many different implementations of its protocol and not one big monopolist dominating the discussion.
In the draft I also wrote that it should be based on Python and Django. When I wrote the draft, I hoped there to already be an implementation of ActivityPub as a Django … plugin(?) so we could just use that, but I haven’t looked into it further.
Additionally, I think some of my ideas aren’t possible to be done easily with Mastodon. Things like “Post ID is version code”, “Comments to posts get published as Atom and JSON feeds” (to get easily displayed on the web and in the app), “Permanent link to latest comments” and “Internationalization through subdomains”.
Another question: why should it be build on top of Mastodon and not on other, more lightweight software like for example Pleroma?
You see, there are still many unsolved questions but exactly therefore I published this draft. From the feedback I received people seem to like it and your offer to help is highly appreciated. To continue, we should discuss exactly things like those mentioned by you and work on the roadmap, to have a plan where to start and what to do.
Implementing ActivityPub from scratch seems like a ton of effort, for almost no gain. The protocol is pretty complicated, and you’re missing a lot of features by writing an implementation from scratch. Things like:
moderation (reporting or blacklisting users)
web interface
option for app developers to post from the app account
All of that we would get for free by using Mastodon or Pleroma like you said.
Mastodon already supports RSS for profiles, maybe Pleroma does too. Not sure about the other items, but if they are required, it would probably be easier to implement them in Pleroma, than write everything from scratch.
I’m happy to discuss this more, but I’m not sure what the best place is for the discussion.
@nutomic You’re right, implementing ActivityPub from scratch is a lot of work and for us as developers we could make our lives easier by just using Mastodon’s or Pleroma’s API. But then, imagine that every F-Droid repo would need to deploy all that stuff and fdroidpub in order to integrate their repo with the fediverse. I’m sure not many people would do that. So by making our lives easier once, we make admin’s lives more difficult repeatedly.
I actually think we’re pretty good here in the forum for the initial discussion on how to start. Later, when it comes to several different tasks, we should switch to dedicated issues in fdroidpub’s issue tracker.
So I investigated a little bit and it seems we’re not the only one looking into an implementation of ActivityPub for Python/Django.
There’s an activitypub-example built on Django and already supporting quite some functions. It did not receive updates for a long time, though.
Then there’s activitypub by dsblank, an actively developed Python API for ActivityPub. It isn’t built with Django, though, and therefore needs some kind of database like MongoDB, SQL or Redis.
Last but not least, there is a discussion for the event manager GetTogether on how to best implement ActivityPub into their software. One user mentions there:
Are you familiar with SocialHome? They are one of the federated social network apps using the Diaspora protocol, also developed in Python/ Django. Perhaps the developers of SocialHome and GetTogether could collaborate on figuring out what existing Python/ Django code there is for exchanging event data across federated networks using standardized protocols?
It would be great if we could combine common functionality into a core library. I’m just now starting to work on packaging up the AP+database logic. If I can help make this activitypub library useful for GetTogether, I’d love to. Help and suggestions welcome!
In my honest opinion, we should reach out to GetTogether and dsblank for working on a native Python solution together. All the stuff you mentioned (moderation (reporting or blacklisting users), web interface, option for app developers to post from the app account) is not specific to fdroidpub’s need, but could be built into a core library shared across all those programs.
Thank you for your thoughts in this topics. I really appreciate the discussion.
I don’t think most F-Droid repos would need to deploy a Mastodon/Pleroma instance. Most repos I know only host one or two apps, so they could simply manually sign up for an account on an existing instance. IzzyOnDroid’s repo is the only one I know with a significant number of apps, I don’t know if he would be interested in this. So I don’t think this should be a focus for the initial implementation.
If deployment is your main concern, we could probably simplify this a lot by creating a docker container or snap that contains everything necessary to get started.
The projects that you linked seem really bare-bones, and missing a lot of things. And I’m pretty sure the shared library they are talking about would only include the ActivityPub implementation, not any kind of frontend. I just don’t think we have the manpower for that.
I had no time to dig into this (and won’t have in the next weeks). But a few thoughts on this in relation to me and my repo:
if I understand correctly, that would mean setting up an account for each app. Many apps in my repo are “in transit” (until they’re finally listed in the official repo), so this won’t make much sense here for those. For the other apps, I’d lack the time to set that up manually (and to figure which app belongs into what category). And hosting my own instance for this is nothing I plan on.
as for the toots themselves: no changelog here, so all the toot could hold would be along the lines of “updated to v1.2.3”. Sure I could add results of VT scans; a list of libraries contained would go beyond the 500 chars and not much helpful either, a number of libraries contained not saying much. So I don’t see what help that would be here.
no idea on how to implement that at my end: would fdroidserver initialize the toot whenever something new is found – or would there be something watching the index? Would “account creation” on new apps be automatic? Would accounts be automatically deleted when an app disappears from the repo?
It all sounds interesting, sure. But I don’t know if I’ll have time to set it up or even to dig in to understand what’s involved. If it’s something done within an hour, I’d be open to it – provided it makes sense for my repo .
That’s true, there are only these two large repos that handle many apps. But I see ActivityPub as a possibility to truly federate, where in an ideal world repo maintainers would just have to deploy the “tiny” fdroidpub thing and be good with it.
But your points are rights. With the help of Docker, deploying even Mastodon or Pleroma should be easy and we are lacking resources to implement everything ourselves. Your proposed method of using Mastodon’s or Pleroma’s API to get out a first working version of fdroidpub seems to be the better option in our situation. To not let my idea die completely we should at least have in mind that we could switch to some kind of python-django-activitypub library later once it’s available.
No. In my idea, fdroidpub would handle all that stuff automatically and the only task would be to install fdroidpub and configure the repo URL. This also answers your third question: repo maintainers should not have to set up anything with fdroidserver and instead fdroidpub should monitor the repo and should automatically react on changes.
That’s OK, I think, as posts would not only notify about updates but would also offer a central place for where to discuss apps. Things like changelogs are the sweeties completing the user experience, but aren’t necessary imho.
My goal is that it’s even less work. Spin up the docker container with the repo’s URL and let it federate! (Then there’s of course some kind of work like deleting spam, but optionally that could be filtered our outsourced to other people.)
Thanks for clarification, @NicoAlt – in that case, count me in! (as long as the dependencies are not too heavy; I’ve got no docker experience at all, don’t have it running anywhere even)
About the process: I’m building the index on one machine and then publish it to another. Which one would fdroidpub need to run on then?
Will we have some switch in the fdroidserver config which cares for automatically announcing the URL for each app? Would be nice to call people’s attention to it. At a later point, maybe the link could even have a number next to it, showing how many comments exist.
Just hoping those comments won’t be abused. After all, nobody can check whether the commenter has used the app at all. Seeing some comments on Playstore, I’m a bit worried about that.
That’s the good thing about Docker, that you just need to install that and then don’t have to care about any dependency. This forum for example is built with Discourse which itself has a looot of dependencies. But as the official way to deploy it is Docker, and Docker itself is pretty lightweight and doesn’t require much dependencies, there’s no problem with it.
That’s another good question. Actually, it doesn’t matter where you deploy the program. I would not deploy it on the build server, though, for security reasons.
You can use any publicly reachable server with some DNS address, and you’re good to go. This could be the server on which you host the repo, but it doesn’t need to be that one.
I wrote somewhere earlier that the first step would be just showing the link to the comments and then later we could fetch the comments of an app and show them directly inside F-Droid and on the web. So yeah, some information inside the index about fdroidpub would be needed.
This is true. And if we care about privacy and freedom as we do now, we’ll have to live with it, I guess. That’s more a social than a technical question. At least, Mastodon implements pretty good spam moderation techniques.
The next thing we should decide is probably whether we should use Mastodon or Pleroma. I never hosted either of them, so I don’t know how big the difference is. Pleroma also has RSS/Atom feeds for users built in, here’s an example. But we might have to implement other feeds ourselves. And Pleroma is API compatible with Mastodon, so we can use the same libraries, like this one.
Some comments in things you mention in the readme:
Account IDs based on apps’ package name (e.g. @org.fdroid.fdroid@pub.f-droid.org)
This is pretty ugly for users. I think in 99% of cases, we can just use the app name, and resolve conflicts manually.
Post ID is version code (e.g. /@org.fdroid.fdroid/1003051)
This sounds like a gimmick, I don’t really see the point.
.