3 ms·

I think he's wrong. Honestly the idea that "social" needs a protocol isn't right. It's that services need a protocol. HTTP was about information retrieval, it w

by asim 4y ago

I think he's wrong. Honestly the idea that "social" needs a protocol isn't right. It's that services need a protocol. HTTP was about information retrieval, it wasn't about services. It was simply about rendering web pages, we then moved into creating services on top of that. SMTP was very much about text based messaging asynchronously. That scaled very well. XMPP failed due to it's complexity. Any social protocol IMO would fail due to this inherit baggage in attempting to build it for Twitter like behaviour. What we need to do is separate out what is the service from the protocol. The protocol is simple, we need a way to communicate with services that provide some functionality that's action driven. The services themselves can then implement all the complexity, but they too should be open, but most likely open source with open APIs. People are getting lost in the dream of a twitter protocol. It's not the right framing. We have a bigger issue. All current centralised services are closed source and closed APIs. We need open source services and open APIs with an agreement on a communication protocol that goes beyond HTTP. What's frustrating is this will mostly fall on deaf ears and I don't think Jack or anyone at his level is the person to execute on this. I don't think high profile people or high profile projects are going to do it. It needs time to bake in a different way. It needs actual use before it sees the light of day.

red_trumpet 4y ago
> We need open source services and open APIs with an agreement on a communication protocol that goes beyond HTTP. I don't disagree, but wouldn't that be a "Twitter Protocol"? For example ActivityPub does this?
- asim 4y ago
  I think ActivityPub isn't so much a protocol as it is an API. Doesn't matter that it has a spec, it's just something defined on top of HTTP. There' an API doc, you can implement it. Has some nice interop. Essentially ActivityPub is a Mastodon API at this point. Twitter is a centralised platform, a Twitter protocol would just end up looking like a documented API spec which anyone could then implement. It's a bit like AWS S3. S3 has now been implemented by most of the major cloud providers and there's some other open source software that does it too. Does it make it a universal storage service? I'm not so sure, but at least you know you can get data in/out of these various clouds using it. Social as a protocol came close in XMPP but anything in this feed/timeline model doesn't have a good solution yet and I'm not seeing ActivityPub as that either. I'd be more inclined to lean into an open API for social and a protocol for communication between services that lets us build on top of these things in a standardised way. Because even open APIs evolve and move too quickly to bake too deeply into a protocol. We need to strike a balance between the things that need to evolve versus the thing that need a stable interface. Protocols give us stability with an envelope for something that's constantly changing.
toomim 4y ago
Yes! This is the approach we're taking at https://braid.org https://braid.org -- extending HTTP itself into a decentralized synchronization protocol, so that any application built on top of it can be decentralized. Specifically, you can divide any application's protocol into two parts: - A data synchronization protocol - A data schema on top of that protocol Existing decentralized social protocols (like ActivityPub) encode both the data synchronization and a set of data schemas into a single protocol. ActivityPub lets you broadcast a bunch of tweets to a bunch of subscribers, but doesn't work very well for other features, like decentralized moderation. It's hard to add new features to these protocols because you have to go through the entire consensus process for each feature. This makes it hard to improve ActivityPub to add new features, such as decentralized moderation. Instead, Braid tackles just the synchronization, with a very simple extension to HTTP, so that different applications just boil down to different data schemas. These data schemas are very easy to translate between (manually, or automatically), which means that any individual application can innovate to its heart's content on new features, and any other application can easily synchronize with any of those new features, to interoperate, and grow a decentralized web of state + features. As an example, here's a prototype for decentralized moderation that we are building on braid: https://peeryview.org https://peeryview.org. See https://peeryview.org/about https://peeryview.org/about for a description.

by asim 4y ago

red_trumpet 4y ago

> We need open source services and open APIs with an agreement on a communication protocol that goes beyond HTTP. I don't disagree, but wouldn't that be a "Twitter Protocol"? For example ActivityPub does this?

asim 4y ago
I think ActivityPub isn't so much a protocol as it is an API. Doesn't matter that it has a spec, it's just something defined on top of HTTP. There' an API doc, you can implement it. Has some nice interop. Essentially ActivityPub is a Mastodon API at this point. Twitter is a centralised platform, a Twitter protocol would just end up looking like a documented API spec which anyone could then implement. It's a bit like AWS S3. S3 has now been implemented by most of the major cloud providers and there's some other open source software that does it too. Does it make it a universal storage service? I'm not so sure, but at least you know you can get data in/out of these various clouds using it. Social as a protocol came close in XMPP but anything in this feed/timeline model doesn't have a good solution yet and I'm not seeing ActivityPub as that either. I'd be more inclined to lean into an open API for social and a protocol for communication between services that lets us build on top of these things in a standardised way. Because even open APIs evolve and move too quickly to bake too deeply into a protocol. We need to strike a balance between the things that need to evolve versus the thing that need a stable interface. Protocols give us stability with an envelope for something that's constantly changing.

toomim 4y ago

Yes! This is the approach we're taking at https://braid.org https://braid.org -- extending HTTP itself into a decentralized synchronization protocol, so that any application built on top of it can be decentralized. Specifically, you can divide any application's protocol into two parts: - A data synchronization protocol - A data schema on top of that protocol Existing decentralized social protocols (like ActivityPub) encode both the data synchronization and a set of data schemas into a single protocol. ActivityPub lets you broadcast a bunch of tweets to a bunch of subscribers, but doesn't work very well for other features, like decentralized moderation. It's hard to add new features to these protocols because you have to go through the entire consensus process for each feature. This makes it hard to improve ActivityPub to add new features, such as decentralized moderation. Instead, Braid tackles just the synchronization, with a very simple extension to HTTP, so that different applications just boil down to different data schemas. These data schemas are very easy to translate between (manually, or automatically), which means that any individual application can innovate to its heart's content on new features, and any other application can easily synchronize with any of those new features, to interoperate, and grow a decentralized web of state + features. As an example, here's a prototype for decentralized moderation that we are building on braid: https://peeryview.org https://peeryview.org. See https://peeryview.org/about https://peeryview.org/about for a description.