I really by and large have mostly lost faith that anything short of a miracle will get #ActivityPub to where I would like it to be, and the forces working against success here are just hard to even look at
I support the groups that are trying to define a way forward, and I suspect in many, many ways the battle is lost until and unless one of those efforts succeeds well enough to define a better way forward, and there's no way to know what that would look like or if it is even possible.
fair interpretation, but i wasn't referring to "the FOSS community", which i agree isn't really a cohesive entity.
i think the potential of the fediverse comes from the ability for affinity groups to create interoperable platforms and possibly cross-community solidarity. i'm excited for the possibility of new paradigms of social organization to bloom in the chaos of the fediverse. i appreciate the potential contributions of the distributed systems people that are on the network now, but mastodon didn't make the network blow up through any kind of technical prowess or vision. they had a marketing budget.
(i would add, i'm not trying to have an argument with anyone. if you think that's what's happening i'm sorry, but i'm not going to have a conversation in that format. i'm just sharing some thoughts.)
No point in moving your identity if your content server shuts down unexpectedly. I'm actually working on nomadic content over ActivityPub right this moment. Centralising it destroys everything I've done with nomadic identity over the last dozen years. We have clonable identities (identity and content) right now with live synchronisation. If your server cert expires or goes offline right this second, go to your clone and nothing has changed. You have all your content, friends, and settings. Everything. I'm not giving this up and neither should you. Content-addressable mechanisms don't work because the url changes if you edit the object. Every project has completely different URL paths and object-type mappings.
I'm currently convinced the only way to solve this is with a mapping table, so that /item/something on my system can be found at /object/something on your system (or whatever). We also have 30-40 different object types that most other projects haven't even considered. This is the only way to make them portable. Just store the object in the mapping table instead of the local path mapping for that object. Done. The portable url could just be $apgateway/$did/$resource-id. If my software supports that kind of object I'll redirect to where we store that kind of object. If it doesn't, I'll just return the portable object.
@smallsees@erlend@dmitri (also the spec indirectly explains how to build a microservice that could run for $1/mo on a little heroku-style platform you could point myname.com at-- we can hopefully provide a prototype soon and, if people demand it, add more explicit detail about how to build one's own or adapt the idea to other form factors?)
it's often so complex to add #ActivityPub to an already existing platform (for example #WordPress ) and it gets even more complex if it is not built for social media 😱
For example
Deleting Users from the Fediverse, that still exist on the blog.
Delete the whole blog from the fediverse, but take temporary plugin deactivations/deletions into account.
@dajb excitedly following the #OpenBadges project! We’re working on something that’s very aligned. Give us a few more weeks and I think it’ll become increasingly self-explanatory.
I'm looking for a well put together written case for institutions (academic, professional) to set up their own Mastodon instance.
Something that not only highlights the obvious benefits, but also that the technical costs are within the capacity of most places that have a decent IT department.
Please do not make the case here, I'm looking for links. 😜
🚨 INTRODUCING: a new in-progress #rubyonrails#activitypub engine that aims to make it able to add AP features to any Rails app.
It's still a work in progress but i would really love to hear your feedback and ideas on that! Feel free to message me here or open a discussion on github repo.
Version 0.10.0 of #Fedify, an #ActivityPub server framework, has been released! Starting with this release, Fedify, previously distributed under AGPL 3.0, is now distributed under the MIT License to encourage wider adoption. Here are the major changes:
• In addition to RSA-PKCS#1-v1.5, Fedify now supports Ed25519 for signing and verifying the activities.
• FEP-521a: Multiple key pairs can now be registered for an actor.
• FEP-8b32: Implemented Object Integrity Proofs.
• Added Arrive and Question classes.
I'm very excited that the #Ghost team has chosen #Fedify to implement #ActivityPub. I've been working closely with the Ghost team, and it's been a lot of fun, and I can't wait to see the ActivityPub implementation at Ghost.
I checked the official website of #OpenGraph (see: https://ogp.me) and I don't see the fediverse: namespace anywhere. Which means this fediverse: namespace is not an OpenGraph tag and will more likely not work without a proper prefix namespace, correct?
So, what am I missing here? People are already adding it. O_O
Update: Relevant thread/discussion about this fediverse: namespace.
As I mentioned elsewhere, there is a case for providing json-ld metadata - which is already in use and has been blessed by Google (not that I care) and dumping both OpenGraph and X/Cards in favour of open standards over proprietary and non-extensible solutions. The Alphabet currently only blesses @context values using schema.org, but this is where the fediverse can assert a standard context that works for us and just start using it. And it's already defined!.