@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.
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
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.
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.
I feel you on that. That's a fair point.
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.
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.
@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
@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.
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.
@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.
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
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.
@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: https://dustycloud.org/blog/spritely/
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
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.
@jdormit @Are0h @sean @kaniini That's _still_ something that can be worked around. In the #IndieWeb, there's a service that converts from different protocols (http://granary.io/) and even backfeeds and emits stuff to other platforms (http://brid.gy/ and http://fed.brid.gy/). We can push forward without leaving anyone behind.
@jalcine That's fantastic...thanks for linking to that!
I had too many thoughts about this to fit here, so I wrote them up in a blog post: https://jeremydormitzer.com/blog/activitypub-good-enough-for-jazz/
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 :)
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
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.
I get that, but we didn't. It's a new protocol and navel gazing doesn't really get us to where we need to be.
I don't see that as a problem, but rather as an opportunity to build. We're not always going to have the opportunity start from scratch, but we can improve. Wether people adopt or not is another thing, but this a great time to influence how people implement.
Maybe, but if the idea is good, it will play. Use proliferation instead of fighting against it.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!