ActivityPub: a federated social web standard
1–10 of 57 posts
Re: ActivityPub: a federated social web standard
#2This is neat stuff. I see immediately how it interacts with things like Mastodon and MediaGoblin. I'd like to see how it could be made to interact with IndieWeb stuff. Particularly, how minimal could you make an ActivityPub server and still have it federate with the things you want it to federate with?
Re: ActivityPub: a federated social web standard
#3So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features of decentralization. Even providing that verb seems kind of deceptive to me; it implies that content that enters the network, could conceivably be purged, which will affect how people use the network. Perhaps DISOWN would be a more accurate verb, especially if it would only be accepted from the original owner.
Re: ActivityPub: a federated social web standard
#4Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.
Re: ActivityPub: a federated social web standard
#5Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.
A URL always includes the scheme. `http://www.example.com/1/ ` and `https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.
Re: ActivityPub: a federated social web standard
#6Cool, open standards are a good thing :) good discussion going on here: https://github.com/w3c/activitypub/issues/ if anyone has questions on the protocol or just doesn't understand some of the writing.
Re: ActivityPub: a federated social web standard
#7I really like the idea of a social web standard.
This seems like a very constricting protocol, though: the one-to-one correspondence between a user and a server means I need to individually post my activity to the "inbox" of everyone who wants to read it (or they poll my "outbox" - I'm not sure). Not a recipe for an efficient system. It's called ActivityPub, so this was clearly a design decision to meet the goal of being decentralized.
But I probably wouldn't implement this standard in a project unless I modified it a bit so that many clients could share a server.
Re: ActivityPub: a federated social web standard
#8I like this. Very Much.
Adding 'Build ActivityHub test server' to my ever growing to-do list! If we build it, THEY* will come.
*Everyone else, obv.
Re: ActivityPub: a federated social web standard
#9I really like the idea of a social web standard. This seems like a very constricting protocol, though: the one-to-one correspondence between a user and a server means I need to individually post my activity to the "inbox" of everyone who wants to read it (or they poll my "outbox" - I'm not sure). Not a recipe for an efficient system. It's called ActivityPub, so this was clearly a design decision to meet the goal of b…
There's JSON examples that include following/followers lists. I'm guessing that you could POST to that list, and the backend server takes care of forwarding it on to your followers.
Re: ActivityPub: a federated social web standard
#10Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.
A URL always includes the scheme. ` http://www.example.com/1/ ` and ` https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.
That is the definition of a URL, but not a law of nature. If these keys would be more useful with the scheme being implicit, then perhaps they shouldn't be URLs.