31–40 of 57 posts
Small section about how Spam should be handled somehow by a server. Sigh. How about we build a federated spam/harassment prevention system first? I have little hope that a spec not designed to reduce/stop harassment up front can have it bolted on later successfully.
It's only a "candidate" so far, maybe you can add some suggestions?
Earlier quoted context omitted.
It's only a "candidate" so far, maybe you can add some suggestions?
I believe they did give a suggestion, to build it before making the assumption that it works.
Earlier quoted context omitted.
If the social contract says "delete things when you see a delete message", then that's useful in a federated environment. Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact. Consider the adversary "angry ex-boyfriend."…
>> most bad actors don't own a time machine You mean besides me, of course. XD EDIT: It's a joke people, for Pete's sake.
I 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…
I 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…
Have a look at the related w3c spec WebSub that is designed to deal with this issue: https://www.w3.org/TR/websub/
Looking 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.
While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http://(.) to https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..
So, 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…
Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.
The standard is awesome and looks well-designed. The biggest issue is that it was lead solely by the people around Mastodon/Pump.io/Mediagoblin. While not a bad thing per se (on the contrary, it shows a commitment to a free internet), it means that there is little chance for it to penetrate the general (social) networking scene (Facebook, LinkedIn, Twitter, VK etc.). Did you try reaching out to each of those major so…
What possible benefit would it give companies whose entire business value revolves around their data...to just give that data away to anyone?
Here's what I learned from working on the DIASPORA* project: The only people that federated/distributed social networking benefits are the 1% of nerds who know how to use it. Everyone else is hopelessly, and willingly, attached at the hip to their social network of choice. Most of the issues or feature requests fell into the following two categories:
1.) I need $FEATURE otherwise I can't use DIASPORA* at all. 2.) Why doesn't $FEATURE in DIASPORA* work like /Facebook|Twitter|Google/? If we made it work exactly like that, regardless of the fact that it makes no sense on a distributed network, we'd be able to actually compete with a $100bil social network! Wow!
Both of these are pipe dreams. With #1, the person is convincing themselves that they want to use D*, but in reality they just want Facebook without Facebook actually owning their data. #2 is the notion that a company like Facebook or Google, who both simultaneously and independently got rid of the last remaining "interoperable standard" in their business: XMPP. Yes, XMPP...once the golden boy of federated discussion platforms...has been totally deprecated by the top two implementors.
Why? Because building their own, centralized IM service is not only more lucrative, it's also a lot easier and less expensive.
The fact that anyone actually sat down and took the time to build specs for federated social networking is a miracle to me...considering there's practically zero business value in it.