>But ActivityPub is also largely underspecified
ActivityPub is not underspecified. Developers might get frustrated when they read the spec and discover that it doesn't explain how to communicate with Mastodon. But this is only because the scope of the spec is much broader. It is a protocol for building all kinds of decentralized social applications, and some of them can be quite different from micro-blogging services.
>We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.
You can create an interop profile for ActivityPub which can be as precise as you want. It can be very strict and at the same time compatible with many existing applications (best practices for interop has been already discovered, and the work on formalizing them is ongoing).
Extensibility is baked in (ActivityPub is a culmination of several decades of experimentation with semantic web concepts).
Of course, you can design a different protocol, but bootstrapping protocols is a very difficult task. #ActivityPub is already popular, and it has all the properties of the Web of Data you've described in your post.
>That said, interoperability with ActivityPub is something we are very interested in.
Interoperability can be achieved by adopting ActivityPub data model (ActivityStreams 2.0). A common language will enable communication without centralized bridges. Transport protocols are secondary
silverpill /
npub19y…5wysk
2024-07-17 20:40:13
in reply to nevent1q…nvzv
Author Public Key
npub19yg7mshq9vdtvvcm48svw03cmzewue4jug62cltnleh3y78khz5sm5wyskPublished at
2024-07-17 20:40:13Event JSON
{
"id": "c1f74ec451589041912b75abfc399950f8c264af40303f05c8fc8c3ac6c8316e",
"pubkey": "2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9",
"created_at": 1721248813,
"kind": 1,
"tags": [
[
"e",
"1e70549ab5f1c48dbb84438f180391ba78a897ea86f538159b685888d375dbbf",
"",
"root"
],
[
"t",
"activitypub"
],
[
"p",
"2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9"
],
[
"e",
"3d08c873c9e599bc0ed25270369e0cdb5ef97f08ec6637c358e4ba185ef303bf",
"",
"reply"
],
[
"p",
"5400e622e1685195531c21da5ee76154066f868f22ff764633ed850516e3745c"
],
[
"p",
"15226b03622be92d6c3a87fc0f35abcb497a8426b0b5351bf1cd9f6b247a1a2f"
],
[
"proxy",
"https://mitra.social/objects/0190c26c-9202-346c-a0e7-cc69eacd409c",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://mitra.social/objects/0190c26c-9202-346c-a0e7-cc69eacd409c",
"pink.momostr"
],
[
"-"
]
],
"content": "\u003eBut ActivityPub is also largely underspecified\n\nActivityPub is not underspecified. Developers might get frustrated when they read the spec and discover that it doesn't explain how to communicate with Mastodon. But this is only because the scope of the spec is much broader. It is a protocol for building all kinds of decentralized social applications, and some of them can be quite different from micro-blogging services.\n\n\u003eWe prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.\n\nYou can create an interop profile for ActivityPub which can be as precise as you want. It can be very strict and at the same time compatible with many existing applications (best practices for interop has been already discovered, and the work on formalizing them is ongoing).\n\nExtensibility is baked in (ActivityPub is a culmination of several decades of experimentation with semantic web concepts).\n\nOf course, you can design a different protocol, but bootstrapping protocols is a very difficult task. #ActivityPub is already popular, and it has all the properties of the Web of Data you've described in your post.\n\n\u003eThat said, interoperability with ActivityPub is something we are very interested in.\n\nInteroperability can be achieved by adopting ActivityPub data model (ActivityStreams 2.0). A common language will enable communication without centralized bridges. Transport protocols are secondary",
"sig": "311c10d1b4d4101921c748c18cb2c0be620de8e0e5a185366c0dded0c3d9e790e49adbc7b1683e47669254d97457cd8970180acbab5a9ffb83e4295d045d65ab"
}