@kaniini Interesting, I had looked at various NoSQL options for MoodleNet, but the ones that fit the criteria well didn't seem to have enough of a track record to take the risk. Curious to see how you get on!
Has anyone done something like this with @nextcloud?
Mounting the main file storage from a USB drive connected to a Pi at home, but running the Nextcloud instance on a remote cloud server (hopefully there's some file caching going on, at least for thumbnails, so that recent pictures remain viewable even if the Pi goes down temporarily, and other data like contacts or calendars should be on the server itself).
@technomancy kids believe that story because that's what we tell them, maybe as an attempt to convince ourselves that representative democracy isn't completely broken (imo it's an inherent design flaw, not an implementation issue or bug)
@kyzh with some good Docker templates being shared it shouldn't be much harder than eg. running Mastodon which by itself already runs several containers
I think most fediverse apps would be better suited as frontend clients (or mobile apps) which can all connect to the same backend server (probably with some backend plugins or microservices to handle things like video compression).
One advantage would be having one federated identity where I can post toots, articles, photos, videos, events, educational resources, git merge requests, etc, etc, rather than having dozens of disparate identities and contact lists.
Clear value proposition, or infinitely customisable?
Slick or austere?
Strictly implementing one vision and set of goals, or adding all kinds of features that different people request or contribute?
Extensive user documented, or code and settings panels (or config files) as documentation?
Historically, the former tends to be proprietary apps, while the latter then to be free software projects that clone the intitial vison/functionality, and then evolve mostly by adding features. The complexity goes up and the UX goes down.
These days we have free software products (eg. Mastodon and Pixelfed) and free software tools (eg. Pleroma).
The question is how do you preserve the user-freedom advantages of tools while gaining the user traction and usability of products?
I suggest one approach could be having a generic backend tool, with standard protocol-based federation and an open API that enables frontend app designers/developers to create slick products that implement all kind of different visions and use cases.
Thanks, in terms of authorization I'm hoping the ongoing work on OCAPs will soon be ready to implement.
I was more looking to agree on conventions for things that aren't in the standard and that implementations aren't doing yet. For example, we want group membership/roles/permissions to federate rather than is restricted to one server. So that I could for example be a 'moderator' of a group on another instance...
@how Who else is implementing Group Actors and where/how can we make sure we are interoperable? (incl. managing membership in groups, roles/permissions, moderation...)