From the perspective of project goals, the project closest to us is Freedombone. We are already in contact with the core developer of the project. Our freedom-maker and Android app projects are compatible with Freedombone. Epicyon, an ActivityPub server developed for Freedombone is being considered for FreedomBox.
There is a long thread on the YunoHost forum about synergy with FreedomBox which seems to indicate that direct code reuse from FreedomBox into YunoHost is not possible. We haven’t yet evaluated the other way round.
As far as I know, we are the only project in this space which completely depends on a distribution’s package management system. Most other projects take one of two approaches - 1) install directly from upstream sources or package management systems (rubygems, npm, pip etc.) or 2) use containers for each application. Both are less sustainable approaches as compared to depending on the Debian ecosystem for most of the package maintenance work. We have automatic updates provided by Debian and are also able to seamlessly upgrade to each major version of Debian. Our approach is also safer in terms of security and privacy. It is a good tradeoff though it might mean that we will have fewer apps to begin with as we have to wait for each app to be packaged for Debian. Even at this pace, the number of apps we had has doubled in the past 3 years.
Projects that don’t use the distribution package manager have to write the installation rules themselves. Debian developers have been doing this for our apps. We only have to care about sane defaults and good configuration settings for our home server use case. So, I can at most expect to share configuration with other projects.
To add to the list, internetcu.be seems to be the home page of the router project that makes use of the yunohost .deb package. And with whom they have collected funds for collaboration.
+1 on the intent to collaborate with other project. I suppose we just have to go ahead and do the leg work.
I guess yes. If the route is to make debian/yunohost app packages to also work on debian/freedombox, at least the immediate benefit would seem to be on the freedombox side. Then however, yunohost packages suddenly run on additional single board computer types, and yunohost benefits from the freedombox maker/build system, sid/testing package availability and test cycles, etc.
The biggest chunk of work I see with the projects is availability of packages in Debian. It is also the area where we can collaborate easily without any other complication over technical decisions. I guess if we work together to make happen packages like Mastodon/Pleroma/NextCloud in Debian. Yunohost can have nice upgrades paths due to Debian packages and FreedomBox can have the apps available in first place. This will also benefit the larger Debian ecosystem considerably.
We can also collaborate on the setup scripts but that is much smaller effort compared to making the app available in the first place and then keep it sane during upgrades.
Yeah, .deb packaging would be another possible collaboration route.
If I recall that correctly though, yunohost has a FAQ item about alternative packaging formats, and that talks about how they have used .deb before, but are now much happier with their _ynh install script packages to include the newest versions of web apps etc.
I am already a user of NethServer and YunoHost. I am eagerly watching Freedombox because I think it could become something great.
I’m new here, so I’m probably going to misspeak on some topics. Sorry in advance.
I think it is a creative and good idea for Freedombox to use a distribution’s packages for software components, but I think it’s a bit inflexible to require that all software be packaged in this way. In my opinion, this decision preemptively kills collaboration with other similar projects. Again, I think this is a great approach for a lot of packages, but it shouldn’t be a 100% requirement. It seems a bit like doing something just to prove it can be done - which I don’t think is the end goal of Freedombox. I think the end goal is to provide a stable yet feature-packed self hosted solution.
I would love to see an alternative option for packaging software for Freedombox that would allow contributors to add functionality that could be adapted to Freedombox, YunoHost, or others, without requiring it to be an official Debian package.
I’ve been looking into @njoseph 's list and I see the technical differences between FB’s pure Debian approach and other ones (container-based or not).
I think that we might find other areas of collaboration.
Would it be feasible to federate hosts so that users of one host might be offered services hosted in other federated host? When the user selects the ‘remote app’ his host should sign a short-lived session-token and redirect the user to the federated host along with the signed token and the federated host would accept the user because the token is signed by a pre-approved host. The signed session token is just one possible implementation, LDAP/oauth-based techniques might offer better choices.
This should greatly enhance the availability of applications reducing the need for personal investments. Providing a service to more users costs less resources and effort than enabling another app. If we make this federation deployment-agnostic our users might jump from FB to YH or others and vice-versa and both (each) project(s) might keep their personality (some oriented to small machines at home, other more open to community/bigger group services, some might provide paid services while others not, some focus more on security while others on privacy, etc).
Security and public reachability are other common areas/concerns that might be fields for collaboration. Basic installation of Debian on SoC hardware, publicity for self-hosting, common presentations, partnering with hardware manufacturers/appliance sellers, performance meassurements, application testing campaigns, etc…
And what’s more important: it would be a starting spark. Once we start inter-project communication it should get more and more fluent, paving the path for further collaborations.
Can you explain significant differences between these directions?:
Decentralization of the "clouds" (decentralizing hosting efforts, regular non-meta-data (payload-) traffic and the "liability" of central gate keepers, which however arrange to remain in the loop and power)