Idea: a federated electronic library, where you upload your ebooks, and give access to others in the Fediverse. How could it work for actual book access? It shouldn’t be embedded in AP objects, should it be just hard-to-guess links? Torrent, like Peertube? How would it integrate with other more generic AP software (Pleroma, Masto)?
@mayel This is a really clever way of helping people, thanks for sharing. I think "choose your own adventure" type tutorials are underutilized as a teaching tool.
""" LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts. """
@adfeno@wilbr@bob Taler is great, and I'd love to see credit unions and other financial coops working with them to get some production instances up and running. But it's just a payment processing system. Funding free code development is well outside the scope of their work.
@wilbr@bob a friend is working on a system for funding public software development where (from memory) users will be able to choose how much to donate, and list the software and services they know they are using. Algorithms then use a database of dependencies to work out how to divide up their donations between all the projects they use (directly and indirectly), and send batches of donations to projects on a regular basis (eg weekly or monthly).
It is a challenge to use AP and still move to agent-centric communications in the fediverse. But I think it is important to do a minimum straight-up AP graphql api for the #commonspub C2S interface, so I'd like to try to get it to all mesh happily.
>"- Users can have several Actors. Actors can have relationships (and capabilities /permission) with each other. "
This is the one that I find possibly problematic. I think the goal should be for each person to have one Person actor for themselves, period. A Person can have many User (credentials) over time and for different methods of credentialing.
At the same time, people like to segregate the parts of their lives - so we would need a way to do that without creating more Persons. Adding something like Profile or Persona could solve that. Also, as Groups become supported and Persons can join Groups, that will become another way to scope conversations.
Here is a quick sketch of something that might work without changing AP, just extending it. Profile is a new actor type. A Person can have many Users. A Person can have many Profiles. Feedback welcome!
I agree with @Gargron about ActivityPub Client-to-Server API putting a lot of work onto the front-end, but at the same time that would allow more functionality (especially to do with supporting other types of activities and objects) and innovation to be focused on the client side, which would make identity a bit less messy (people could follow me once and get my toots, video, photos, etc, and vice versa, I could have one unified timeline mixing different kinds of content). The answer to "what's a good alternative to Facebook" isn't one platform like Hubzilla, it's an ecosystem of truly interoperable apps. We've got the right tools, we just need to tie them together in useful and non-competitive ways.
A few of us are working on adapting the Client to Server API into a GraphQL schema, which I think will provide the best of both worlds, lots of flexibility for client apps while being easy to implement as the server can still to most of the ActivityPub/ActivityStreams heavy lifting.
Some of our immediate goals for #CommonsPub include:
- Federation that works for any type of activity, object, and field (including extensions). Side effects could be controlled by a sort of plug-in system similar to WordPress (including just bridging to an existing non-Elixir app's API). #MoodleNet will be a plug-in that extends #CommonsPub.
- GraphQL as the primary client API, with some generic very flexible and powerful (but complex) endpoints, and plug-ins being able to add endpoints to make things easier for their specific use case or client app.
- Support for Groups.
- Users can have several Actors. Actors can have relationships (and capabilities /permission) with each other.
- More kinds of Actors, including Group and Organization.
Some goals we don't have right now (put would accept merge requests for) :
- ActivityPub C2S API
- Mastodon API
- A server-powered no-JavaScript-needed basic HTML client, extensible by plugins
One of the goals of https://gitlab.com/OpenCoop/CommonsPub/Server (still in development) is making projects like that much easier, to the point where it may mean just creating or adapting a front-end app
Hey @kaniini it's a bit all over the place right now, but we're hacking on it intensely this week (including the GraphQL API and starting to hook up MoodleNet's front-end) so should have something partially functional afterwards. Our launch date is somewhere in January though.
@drumsetmonkey Firefox is Fennec Browser on F-droid, Youtube client is NewPipe or Skytube, Whatsapp isn't on F-droid but Telegram is, for a basic email client you can use K-9 Mail. For Twitter you can use SlimSocial, Twitlatte or Twidere. For Android Keyboard or G-Board I use Simple Keyboard.
"It is not violence the ruling classes object to; for they themselves rule by violence, and take with the strong hand at every door. It is the social change they fear, the equalization of men ... What! These creatures who drill men in the science of killing, who put guns and clubs in hands they train to shoot and strike, who hail with delight the latest inventions in explosives, who exult in the machine that can kill the most with the least expenditure of energy, who declare a war of extermination upon people who do not want their civilization, who ravish, and burn, and garrote and guillotine, and hang, and electrocute, they have the impertinence to talk about the unrighteousness of force!"
@strypey Apart from Kevin"s work, I'd recommend taking a look at @Gin 's initial work (beyond labels and branding) on the ways that genuinely progressive organisations aware of the limitations of capital can tell who are compatible organisations to cooperate with. (And which aren't) Hopefully a first deliverable of many. http://emo.world/2018/09/27/no-profit-no-hierarchy-a-comparative-study-of-the-lower-left/