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 
@NicoAlt Very cool idea!
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.
2 Likes
@nutomic Thanks for the kind words!
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.
1 Like
@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?
The author of the secondly mentioned library seems to be open for collaboration:
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.
3 Likes
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.
1 Like
@TPS thank you for pinging @Izzy.
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.)
1 Like
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.
2 Likes
Great to hear! Thank you for your interest!
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.
1 Like
I’m glad you agree.
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.
1 Like
That’s right. I neither hosted on of them, so we are on the same level of knowledge here.
Mastodon has this, too. Here’s the atom feed of F-Droid’s account for example.
Especially a feed for comments of a post, as I did not find one when looking for it.
I designed it like that to make access from F-Droid’s web and app easier. We would just need the domain of a fdroidpub instance in the index and would be able to link to all accounts and posts without any further information.
Application
org.fdroid.fdroidhas version code1003051as latest one in the index. The refering post is athttps://pub.f-droid.org/@org.fdroid.fdroid/1003051.
But I agree with you that the UX of account names is not the best. Going with names of an app, what do we do when an app’s name changes? Also we would need some kind of mapping database between application IDs and their account names.
I don’t think app names change often enough that we should really worry about that. If it ever happens, we could use the account migration feature in Mastodon, like I did here: https://mastodon.social/@nutomic (see the right side, “Felix has moved to …”). I don’t know if this is supported in Pleroma though.
Yes we would need to store some extra data, but I think it’s worth it. The simplest option would probably be to store it in the app’s metadata.
Btw it would be really good to get some input from a Mastodon/Pleroma dev to figure out what exactly we’d have to implement, and how hard it would be. So I made a toot about this on Mastodon: https://soc.ialis.me/web/statuses/100664228935460858 (maybe you can boost it with the F-Droid account)
1 Like
Wow, one share and now I’m getting nonstop notifications for boosts and favorites 
1 Like
What I can suggest is to implement ActivityPub directly instead of using APIs.
The Fediverse (see: https:/en.wikipedia.org/wiki/Fediverse) is a large federated network comprising of different software and protocols. The main protocol with the largest support currently is ActivityPub, thanks to it being a W3C recommendation. There are also the web- W3C recommendations (webmention, websub, etc.). There are also other protocols like diaspora*, DFRN, OStatus (actually succeeded by ActivityPub), Zot, and others.
From what I see currently, the Fediverse is being approached as “Mastodon” and “Pleroma”. I strongly suggest to approach it as ActivityPub and you’ll find it easier to connect to the fediverse directly than using a particular software, especially since Mastodon and Pleroma are only two of many software which are connected to ActivityPub protocol/network – there is Misskey and Hubzilla to mention two more.
Also, there is no need to create accounts one for Mastodon, another for Pleroma, another here and another there. By implementing ActivityPub directly into Fdroid, “identities” (or accounts if you will), simply has to connect to a particular App to receive updates/notifications.
Example:
user1@mastodon.tld adds/follows/subscribes to @app1@fdroid.org
user2@pleroma.tld adds/follows/subscribes to @app2@fdroid.org
user3@hubzilla.tld adds/follows/subscribes to @app1@fdroid.org
user4@misskey.tld adds/follows/subscribes to @app1@frdoid.org
When App1 uploads a new update, the fdroid system will create a short update. Anyone who is following @app1@fdroid.org will receive this update.
There is no need for the maintainers and/or devs to create an announcement account because their App’s fdroid repository link is an actual ActivityPub “channel”.
You can also free your main fdroid account from posting updates of different apps that for sure most followers won’t care about. By implementing ActivityPub directly instead of relying on creating an account in software1, software2, software3, you are also giving users the option and an easy way to subscribe to only those apps they do care about. While your main fdroid account will serve as an announcement for the project itself, not an “app update” announcement “channel”.
For me, this is the best option and less headache. You don’t have to worry about what-if a dev transfers to another server, especially since there is no cross-software account transfer.
Take a look at projects like PixelFed, Write.as, and PeerTube. PixelFed is an Instagram-type software federated with the ActivityPub protocol. Write.as is a blogging software. While PeerTube is, you guessed it, a YouTube-type software which is also federated in the fediverse.
When a user in a PeerTube server uploads a video, anyone who are following that channel will receive an update. If someone writes a new blog post in a Write.as server, same thing. Likewise when someone uploads a new photo in a PixelFed account in a server of their choice.
For Fdroid, those channels are the Apps itself.
Here’s the kicker. You can implement a comment system through ActivityPub that will show as a “feedback” or something when the App is viewed (maybe as a separate tab). The App maintainer or developer can also be given an option to reply to those if you want to add that as a feature. It’s all up to you. It doesn’t have to be two-way if it isn’t feasible.
If you can, implement ActivityPub directly, it’s the best option hands-down.
Do it in a structured and official way. Standardize the toot format so that they can be easily parsed by code. (Like protocols) and use F-Droid as some official voice for consensus.
for example: if you are going to use it so that users give a thumbs up/dn on a particular app. The toot format should be standardized so that different tools from different people can understand it, parse it and tally up the numbers.
another example: for multilayer passive games like chess, checkers, etc. They could use the fediverse to communicate. As along as the toot format is standardized you could transmit the game state back and forth.
Standardize a toot format to publish a high score, achievement badges. You could publish a stores open/close hours. A particular toot format that signifies a review. Support for classifieds to allow for something like an open source craigslists.
Fidonet had a good classified ads support, why not mastadon. and now that we are modern lets standardize the toot so that it can be easily parsed by code.
just to add, one can simply submit XML and JSON as toots and use the fediverse as communication for an app. Well its better to have a standard that can hide things meant for machines and not humans. Reduce clutter and avoid spam