Peter Toft Jølving
All the people criticizing competing decentralized protocols owe it to the #ActivityPub-community to work *hard* on making the spec implementable in a straightforward and incremental way.
"Build for ActivityPub or you're harming us all" is unreasonable for anyone to say given the ambiguity of the spec and the effort required to implement it in its current form.
Evan Prodromou
@joelving we have a good primer on the W3C wiki. I am writing a book for O'Reilly. There are good materials on the web. Developing for other standards does everyone harm. Anyone who is stuck is welcome to ask me personally. If your only choice is developing for another standard or doing nothing, do nothing.
Evan Prodromou
@joelving it is easy to run your own server, and getting easier.
Peter Toft Jølving
Even then, we're pretty far off from that being a reasonable statement. #ActivityPub has some pretty hard to mitigate issues around privacy and identity with far-reaching ramifications for trust and safety and autonomy of people rather than server operators.
Evan Prodromou
@joelving there are dozens of AP implementations. Clearly, it's not impossible to implement. It can and should and will be easier. That's no argument for undermining this network. The premise is flawed and the conclusion does not follow.
Peter Toft Jølving
@evan
I know that's what you think, and I very much disagree.
There are good materials and while they help, they do not make it anywhere near straightforward to build for the Fediverse.
Building for specific implementations is easier, but that kinda defeats the purpose.
Evan Prodromou
@joelving ActivityPub is built on extremely mainstream technologies -- HTTPS and JSON -- which have ample tools and support in almost every programming language. There are definitely tricky bits, like signatures, but the essentials are really easy for almost any Web developer. I would gladly put it up against the non-standard blockchain systems in terms of ease of development.
Peter Toft Jølving
@evan
For technical people like you and me, running an existing implementation is doable, sure.
While it helps a lot with the issues around identity, it leaves plenty of issues around privacy and trust and safety, though.
My issue is around creating new implementation, however.
Evan Prodromou
@joelving protocol standards help more software and more people stay connected. A multiplicity of protocols inhibits those connections.
Peter Toft Jølving
@evan
Of course it's not impossible, but that's a pretty low bar.
I do not agree that it's a goal in itself to get everyone communicating using AP. A lot of the values underlying AP, I agree with and are worth servicing, but any particular protocol does not in my eyes deserve the same consideration.
Evan Prodromou
@joelving covering a wide array of social networking activities means having some flexibility in data structures. That can be tough in strongly typed languages. You don't usually have to deal with many kinds of types - just a string, an object, and an array of strings or objects. That's tough with C# since it doesn't support union types, but I think the regular workaround is to use a class with multiple constructors.
Peter Toft Jølving
@evan
Sure, it's json, but any ease of use that might afford is lost with a data model where a property can take half a dozen different shapes.
But I agree, blockchain is poison and not an improvement at all.
Evan Prodromou
@joelving so, like I said, social software isn't easy.
For identity, I'm not sure of your point. URLs make incredible identifiers. Unique, memorable, easily resolvable with standard libraries, highly distributed. The Webfinger abbreviation makes them even easier. What else are you looking for?
Peter Toft Jølving
@evan
I know, there's definitely ways around it, and you can always fall back to working with the raw JSON (not mapping to POCOs).
My argument has never been that it's impossible to implement AP/AS2, just that it's not easy, and that there's issues around e.g. identity that's nigh impossible to fix within the bounds of the standard.
Evan Prodromou
@joelving so, two things. First, I agree about ownership. But we've always expected to have closer affinity between the user and admin -- like with email. It's an employer, your university, or someone you pay.
Second, I like how takahē does it; you can assign multiple domain names to an instance, down to a single user. I think that's a great method, and hope we see more of it.
Peter Toft Jølving
@evan
Ownership. Unless you have the technical chops to host your own server - or money to pay someone to do it for you - your existence is at the behest of your admin.
Shareability. I don't want to have separate identities for every app I use, e.g., one for Mastodon, one for Pixelfed, one for PeerTube, but I must. Each app is simply a lens over my graph, but I can't treat it as such. Maybe this is possible within the spec, but it's not apparent how that would work.
Evan Prodromou
@joelving for apps: I also agree! I think we should have more general-purpose AP servers, and push that innovation to the client. Have a drawing app, a 3D app, game apps, all using the same account on your AP service, but generating wildly different activities.
Evan Prodromou
@joelving I should also point out that `name`, `summary` and `icon` are there precisely to give you fallback representation of activities and objects. If you don't know what it means for Evan to schmork seventeen watanabes, you can just show the image I provided plus the summary.
Peter Toft Jølving
@evan
I hope you don't mind me thinking aloud here - despite my original post, I actually *do* want to build for ActivityPub. That's the source of my frustration.
Come to think of it, I don't need to serve up-to-date representations of all objects, only locally sourced ones, and those are easy to assign an owning app.
So, the apps would simply register a new object and the AP server would the direct queries for the object to it.
Hmm, onwards it seems.
Peter Toft Jølving
@evan
But we want all apps to see everything and they might be able to process some of the same activity/object combinations - who gets to be authoritative if they disagree on the result? I don't have an answer for that.
Peter Toft Jølving
@evan
That is exactly what I'm trying to work on, but haven't figured out how to do.
The combination of Ids being dereferencable and the vocabulary extensible is tough. I'd prefer the generic AP server hosting the activities (easy) and objects (hard) but since everything is extensible and something other than Update activities might mutate the object (replies for instance), we can't know how to keep up-to-date representations of objects, so we need to push that responsibility out to the apps.
Evan Prodromou
@joelving yes. The other thing is good-hearted people who take on more than they can handle. Running a social network for pseudonymous strangers is not a recipe for good mental health.
Peter Toft Jølving
@evan
Agreed, it seems weird to me that a Mastodon instance is so closely tied to its domain name. Nothing prevents it from accepting whatever was pointed at it.
I don't think your expectations around admin are unreasonable, but in practice it seems not to be the prevalent form of organizing and it has some serious consequences with tiny tyrants arising all over.
Evan Prodromou
@joelving I run on wikitime. We might not continue this conversation for another 8 years.
Peter Toft Jølving
@evan
In my timezone it's getting late and with small kids waking me up in way too few hours, I'll have to bid you good night and thanks for the conversation. I appreciate you taking the time.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.