@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.
@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.
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.
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
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 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
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
@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 :)
@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
@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.
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.