@kaniini There are a couple of good points in here, but this is a really cynical take on AP.

I'd agree it has some blindspots that need to be addressed, but lines such as "In an ideal world, the number of ActivityPub implementations would be zero." is pure hyperbole.

Further I would give it more deference if it presented a viable option as opposed to "this is bad, but I don't know how to do it better"

We gotta do better than this if we are to push forward.

@Are0h That's part of the upcoming series. And it's kinda been hinted at on their timelines (leveraging facets of Zot's apporach, using capability URIs vs implied actions, etc) @kaniini

Follow

@jalcine Aight, cool. Hopefully will get better because this isn't a great start.

There are some salient points about security that I absolutely agree with, but most of it just seems like editorializing.

I'd rather see problems identified and then explorations of possible ways to improve.

But I guess they're saving that for later. I hope.

@kaniini

@Are0h @kaniini @jalcine

well, this was meant to be kind of an explanatory post of what my present world view is on activitypub, having spent a year basically bringing up an AP implementation from scratch, and working in a codebase which built on AS2 with some elements of AP as a data model.

so it basically *is* editorializing on the topic.

the next blog post in that series that i'm working out in my head actually has to do with what a merged AP + Zot6 type protocol might look like, and what is good and bad about that. it will also attempt to explain in detail why tying personal identity and cryptographic tokens together is fundamentally unwise (although my post about Blind Key Rotation went into some explanation on why that is unwise too), and introduce a construction of capability URIs and proof responses as an alternative.

@kaniini @kaniini @jalcine

Yeah I know. I just think that's a poor way of going about it.

The proliferation of AP is providing a real opportunity for us to not only think about how we communicate but more effective ways to do it, a couple of which you name, which is cool.

I'm so down w/ the protocol being changed in a way that makes it better, but saying we shouldn't be using it at all is step backwards.

Cool. I'll wait for that. I really want to see viable options. Especially if they work

@Are0h @jalcine @kaniini I think one challenge we have to think about here is how we might be able to positively affect future versions of the protocol spec.

For better or for worse, this whole thing sits in the realm of WC3, and in some ways is the byproduct of attempting to please the multiple groups that populated the SocialWG. You've got Linked Data and IndieWeb people shoehorned into the same space as fedi developers, and many members of the group representing corporate entities that might be interested in a narrow application of it.

So far, the process for advancing the protocol to a new version that is, for example, aware of the notion of OCAP, is largely undefined beyond writing a whitepaper, putting out a CFP, and hoping other people in the space will adopt it.

@sean @kaniini @jalcine Yeah, I agree. And as there is so much attention on it right now, this is a great time to do so.

That part of it is always going to be what it is, but the power of the idea is self evident based on how many good people are adopting. That's a huge plus. We can work with that. There is so much space to make AP better without kicking it in the face.

Which is why I think we'd better served to improve the spec rather than demean it.

Is it perfect? Hell no. But it's a start.

@Are0h @jalcine @sean

It's not my intention to demean it. UNIX (Linux) is a classical example of the "worse is better" philosophy. UNIX won.

ActivityPub will win too. My point ultimately is this: ActivityPub is going to win, but how do we coordinate standardizing security fixes across all of these projects popping up?

Completely redesigning entire parts of the AP protocol is out of the scope of Litepub, we must either try to push forward in SocialCG or create a new standards body.

So, I think we will eventually see a split between those projects which do want to move forward with security and those which don't understand why the emphasis on security is important.

@kaniini @jalcine @sean This is a much better expression of the ideas you put forth in the piece.

I think questions about security are worthwhile. And as the AP spec itself is not set in stone, there is room to make it better.

In light of this, I don't think jumping another protocol is the best way to move forward. There is plenty of room for improvement in AP.

I don't think we need to create a schism around AP just yet. There is space for collaboration and improvement.

@Are0h @sean @jalcine

That's why I said doing radical rework of AP is outside the scope of Litepub, but that we need to decide as a community whether we want to stay with W3C or go our own way.

I am very afraid that W3C revision cycles on things like introducing OCAP will introduce new security flaws, because of the philosophy at W3C. I mean, we can't really expect an organization that promotes the idea that all information should be freely searchable and accessible to understand why you want to put security protections on your private data.

Plus W3C is pushing SOLID now instead of ActivityPub because timbl started it.

So, I don't know. I really don't think Litepub is an appropriate place to just start doing major rework of AP, but it is a pre-existing working group that has the big projects participating, so it would be a start.

@kaniini @jalcine @sean

I feel you on that. That's a fair point.

Agreed.

True, but it has a ways to go before it reaches the stickiness of AP.

It's a risk assessment. Where can create an environment for substantial changes without burning the whole house down.

It's something to think about, but we should give AP a chance to bake before we flip to something else and have a whole new set of issues and we go through this process again.

Let's put effort into making it work.

@kaniini @Are0h @jalcine @sean

Just noting this is a great thread to read for all #ActivityPub actors out there. I hope this is going to show up at #FOSDEM2019 in the Decentralized Internet & Privacy Devroom that "we're smart people: we can walk and chew"

@kaniini @Are0h @jalcine @sean

Quoting from the blog: "But this will require coordination between all the vendors. And with 40+ projects out there, it's not going to be easy. And do we even care about those 40+ projects anyway?"

If we were able to coordinate that many developers, we would be able to implement all services as micro-services that complement each other. There's no reason why this would not be possible... Except ego wars.

@how @sean @jalcine @Are0h

microservices sound nice, and have been experimented with in both the diaspora and pleroma communities, but they aren't really a full solution.

what is needed is a rework of the security posture of AP (how painful this is *will* depend on ego to some extent), but integrating a capabilities model into AP has it's own share of challenges. and of course, it depends on the key players upgrading so that the new projects have motivation to upgrade as well.

but i do think we can get there -- it's just a matter of finding the path.

@kaniini @Are0h @jalcine @sean

I guess good coordination starts with shared understanding.

I really enjoyed reading Capabilities Myths Demolished (srl.cs.jhu.edu/pubs/SRL2003-02) but where to go from here?

@kaniini could #IETF be a better place to do formalization work on federated web protocols than the #W3C? Especially given the way that latter body caved to #DRM #crippleware by including #EME in the #HTML spec. Although even as I type this, it occurs to me that what we need more at this stage, while the tech is still evolving and mutating rapidly, is a standards *incubator* with wide buy-in.
@Are0h @jalcine @sean

@kaniini looking at the history of #HTTP, I suspect that despite AP being officially at v1.0, we're still at the HTTP 0.9 stage of development:
hpbn.co/brief-history-of-http/
@Are0h @jalcine @sean

@sean @kaniini @jalcine AP is popular because it's simple and it works. I absolutely agree the design isn't perfect because it does have some gaping holes, but as a protocol framework, it's really solid.

I say we build on that rather than lamenting the fact an imperfect idea is getting traction.

With all of these big brains floating around the fediverse, I know we can do better than 'this is bad, but I don't know the answer'.

This is such an opportunity to set a positive tone moving forward.

@Are0h @sean @kaniini I wanna agree but we do need to scrutinize these things strictly - especially if we plan on being stewards / promoters of it.

@jalcine @sean @kaniini I don't have a problem with taking ideas to task in terms of long term viability.

But let's not confuse personal tastes with actual progress.

I'm all for putting idea through the ringer to see if they stick. But if we're going to frame one idea as not viable moving forward, let's at the very least have another realistic option in hand rather than theoretical discourse.

We're smart people. We can walk and chew gum at the same time.

@Are0h @sean I think @kaniini has highlighted that with LitePub and the mentions of OCMs (Object Capability Models) in their prior posts on their account. Maybe if that was included in the post, it would have made it clear?

@jalcine Ok, that's fair. That's what I think we need. A more holistic view of what we need open source protocols to be rather than cynical takes on why we shouldn't be using what is working right now.

There's some real heat behind AP adoption at the moment, and I don't think that's a bad thing. That means people are listening right now.

We should leverage that to improve what we have and get more folks involved, not lament it.

@sean @kaniini

@Are0h
This. The challenge of federation is social, not technical. It's a much better situation to have an imperfect protocol that everyone uses than to endlessly iterate - every fork of the shared protocol splinters the network and gets us further away from the dream of an open, connected web.
@sean @kaniini @jalcine

@jdormit @Are0h @sean @kaniini Forking and splintering won't be too much of an issue with tight collaboration amongst projects and that's something the Fediverse has been pretty okay-ish at thus far. It's not like we're relying on a company to define things for us - it's people-driven

@jalcine
Sure, but what are the chances that competing protocols will actually maintain compatibility with each other? The web is built on a stack of shared protocols - imagine if every website didn't use HTTP! ActivityPub is a 90% solution, and I think the last 10% can be built on top of it without breaking compatibility.

@Are0h @sean @kaniini

@jdormit @jalcine @Are0h @sean @kaniini I think AP is under-specced primarily due to constraints impose by W3C (time and otherwise) and a desire to formally pin down as much as possible while Mastodon was ploughing ahead with its implementation to minimize the risk of it rolling out too many bad ideas ad-hoc. I think Chris (Webber, co-editor of AP) is aware of the gaps and interested in seeing them filled. For example mentioning OCAP here: dustycloud.org/blog/spritely/

@msh @sean @Are0h @jalcine @jdormit

Mastodon indeed has caused some minor damage with their AP implementation by moving too quickly, but I think it's minimal compared to the overall under-specification that has occured.

It should also be noted that Mastodon's damage is also in part because Gargron and company were given bad security advice by the W3C Social CG.

The fact that we have to push for a mitigation in the form of rotating keys due to Mastodon's decision to adopt the highly flawed LDSigs signature scheme is an example of the damage caused by moving too quickly.

But we are moving towards mitigating those problems with Blind Key Rotation.

Of course, in an ideal world, no implementation would use LDSigs, and maybe we will eventually convince people to stick to constructions which make sense instead of just copying what Mastodon does.

But here's the thing, Chris wants to move away from technologies that work and towards the experimental stuff. I wish him all the best, but we need to ship things which people can believe in wrt trust & safety, and where we're at right now is not so great for that. I think before we start integrating I2P and DAT we should talk about getting the fundamentals right.

@jdormit @Are0h @jalcine @sean

I agree Mastodon itself has shown good restraint in only causing "minor damage" considering its out sized influence. That said Eugen seemed to be a bit of a catalyst in pulling such advice out of Social CG. It's good and bad in different ways.

Chris is this deep thinker and I think tried to make sure AP was flexible enough to address future concerns, but is the antithesis of Eugen who forges ahead to scratch itches. @kaniini seems to provide balance.

@msh @jdormit @jalcine @sean And just to piggy back on this comment, if it turns out that what Masto is becoming is not conducive to the changes that need to be made to AP, I will abandon it in a _heartbeat_.

Popularity shouldn't be the defining factor of the what the protocol should be. Stability and security has gotta be at the core of it. That's something I hard agree with @kaniini on

@kaniini People are in part copying what Mastodon does because there's no comprehensible documentation for anything, so the logical next step is to try to understand how the biggest player does it. Real documentation would go a long way to gaining mindshare. @msh @jdormit @Are0h @jalcine @sean

@jdormit @sean @Are0h @jalcine

ActivityPub is a more like a 75% solution, not a 90% solution. Maybe from the perspective of syndicating blogs it is a 90% solution, but from the perspective of interconnecting communities, there are many problems: abuse mitigation (which cause strife between users and admins and between instances), broken signature schemes (which endanger activists), lack of deniability (big oof for marginalized people), the lack of being able to directly define what interactions you want with your posts, etc.

Yes, absolutely we can get there, but it's not a "90% solution". There are significant parts of the protocol that need to be revisited and retrofitted with security features.

@kaniini @jdormit @jalcine @sean So let's do that rather than quibble over subjective interpretations of how close we are to a solution.

Whether it's 75% or 90%, we can agree it's getting us closer to where we need to be.

That's a point of common ground we can all work from.

@jdormit
Honestly, I'm not too worried about their being different forks, because that breeds diversity and resists stagnation.

That said, we do need to come to some type of common ground that we can build from. If it's not going to be AP, I want to see a tangible option so the proliferation of the fediverse isn't stunted.

I think we're closer to it than we think. We just need to refine and streamline the many wonderful ideas we have for the protocol.
@sean @kaniini @jalcine

@Are0h
I agree that we want diversity in Fediverse apps and services, but they all still need to share a protocol. If my server can't federate with your server because they dont have a shared language, there's no no Fediverse.
@sean @kaniini @jalcine

@jdormit @Are0h @sean @kaniini That's _still_ something that can be worked around. In the , there's a service that converts from different protocols (granary.io/) and even backfeeds and emits stuff to other platforms (brid.gy/ and fed.brid.gy/). We can push forward without leaving anyone behind.

@jalcine Well said. Let's improve on what we can improve on _and_ explore better ways that present themselves as we learn what works and what doesn't.

We are people well versed in solving difficult problems. We can do both.

@jdormit @sean @kaniini

@jalcine
Granary is really interesting. It still sort of rubs me the wrong way to have multiple versions of a protocol that require a translation layer though - seems like that undermines the whole point of a protocol!

@Are0h @sean @kaniini

@jdormit @jalcine @sean @Are0h

It is not a better situation if that imperfect protocol has gaping security vulnerabilities and broken crypto schemes that can result in real world problems for participants. That is a crossgrade.

@kaniini @jdormit @jalcine @sean This is theoretical, but I understand where this thought comes from based on what we have now.

I don't understand the need to abandon the spec so early when there is an opportunity to shape it a direction that is conducive to security and safety.

If we can fix it, let's do that rather than squander all of the activity around it and start again from scratch. That's not good for the fedi. Constantly reinventing the wheel will send it back into obscurity.

@Are0h @kaniini @jdormit @jalcine @sean There is also always the option of making the weaknesses known to end users well enough, so they won't use a thing for the wrong purpose As in: No one puts anything really sensitive into a real-world postcard, because they understand postcards. So if I understand what to put into a particular social media thing and what not, I can still be reasonably safe.

But I'd prefer to have something more safe too, hence we're working on darcy.is :)

@JollyOrc @sean @jalcine @jdormit @Are0h

SOLID is a downgrade in all respects.

That you don't discuss privacy or future deniability on your landing page speaks volumes too about your own knowledge about this.

So many people in this space come along peddling things that are harmful, and that's part of how we got into the hole we are in with ActivityPub.

@kaniini @jdormit @Are0h @jalcine @sean
We will use Solid as a datastore, not as the networking protocol, and I think that is actually an upgrade when you want to think about data portability.

Regarding privacy and future deniability: I am in a very privileged position of not having to overly worry about these things, so yes, I personally fail at this when writing webpage blurbs. That is why we won't build anything before having talked to people who do care more about this. 1/2

@kaniini @jdormit @Are0h @jalcine @sean
We are expanding the team into exactly that direction: People who don't fail at this like I do.

Also: We don't want to supplant other solutions. Darcy is supposed to play nice with those and respect those communities that have specific needs for privacy or security. 2/2

@JollyOrc @sean @jalcine @Are0h @jdormit

well, best of luck but until I actually see a system built on SOLID that guarantees privacy and deniability, I'm going to remain skeptical and bet on AP instead.

@kaniini @jdormit @Are0h @jalcine @sean
thanks! Also, just as a clarification: We probably won't use Solid as the social layer (which timbl will probably be cross about), but as the datastore. So your content (posts, media, comments) will be stored on your Solid pod, instead of your chosen instance. Instance and Pod may be the same system, but they don't have to.

If you do separate them, you can move instance while keeping your data.

@kaniini @kaniini @Are0h @jalcine Wow, I read about Zot6 yesterday in a wikipedia comparison and on the official webpage and repository of osada jajajajaja

@Are0h
ActivityPub has no basis for expectation of privacy, which this blog was about, and there's no way for instances that require load balancing to safely federate with those lacking that infrastructure. Those are the inherent limitations for ActivityPub over HTTP. If that's not suitable for a specific application, it's probably best to build to AP as social discovery for a future service
@kaniini @jalcine
I'm with @Are0h on this.

I've seen several projects doing these kind of hyperbolic slams at their competition recently.

https://secushare.org/federation just did it, too.

Accurate constructive criticism is useful (and there's some of that in each of those articles). But the hype just muddies the waters and makes me doubt their motivation.

Disclaimer: we're building stuff on a Pleroma fork, and looking into capabilities and Zot.

@kaniini @jalcine
@AceNovo
Sign in to participate in the conversation
Social @ PV

Social is the primary social media platform for the forth coming fourth version of Play Vicious, a new initiative built to bring attention to the plethora of creative acts that don't get the shine they deserve.
For more details about the project and how to support, go here.