Facebook/Meta starts talking about the "Extend" phase of Embrace, Extend, Extinguish as predicted:
"“You could imagine an extension to the protocol eventually — of saying like, ‘I want to support micropayments,’ or … like, ‘hey, feel free to show me ads, if that supports you.’ Kind of like a way for you to self-label or self-opt-in. That would be great,”
For #ActivityPub the question of "Why use #LinkedData?" has never been answered. There should be clear merits to wade through all the complexity that this choice brings, right?
Yes, its ultra flexible, and you can define your own semantic #ontologies, and theoretically it could provide a robust extension mechanism to AP protocol. Except that right now it doesn't.
What's the vision of a Linked Data #Fediverse? What great innovative #SocialNetworking#UX would it bring, that makes it worthwhile?
The fragmentation among friends that follows Twitter’s collapse is exactly the kind of problem that Mastodon and the social web solves for. Imagine that you don’t have to pick and choose which new platform to adopt, or make and maintain a million accounts—because you can follow anyone regardless of which platform they’re on. That’s our reality.
The crybabies who freak out about The Communist Manifesto appearing on university curriculum clearly never read it - chapter one is basically a long hymn to capitalism's flexibility and inventiveness, its ability to change form and adapt itself to everything the world throws at it and come out on top:
So what work does the "open" in "open AI" do? "Open" here is supposed to invoke the "open" in "#OpenSource," a movement that emphasizes a software development methodology that promotes code #transparency, #reusability and #extensibility, which are three important virtues.
But "open source" itself is an offshoot of a more foundational movement, the #FreeSoftware movement, whose goal is to promote freedom, and whose method is openness.
The best part of the fediverse is that anyone can run their own server. The downside of this is that anyone can easily create hordes of fake accounts, as I will now demonstrate....
In Activity Streams 2.0, an “extension” is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions must not stop processing or signal an error and must continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined. Accordingly, implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
My point is that votes (as Like and Dislike) exists within ActivityPub and while an instance can chose to ignore them (or not), they’re there. You can’t get rid of votes. You can set up an instance to ignore them. You can tweak it so that it won’t even accept likes or dislikes from other instances… but you cannot get rid of them.
If someone doesn’t want their content voted on in another instance that does have votes enabled, then… well… I’m not sure what to suggest as its part of the spec.
Could we not use this same tactic? I would love to see a Terms of Use drafted that requires federation participants to fully support the project. It could prohibit partial implementations, especially if extensions to the standard were being added before fully supporting the standard. Actions that seem to use embrace, extend, extinguish tactics could be explicitly called out and forbidden.
What is a “partial implementation”? We’re coming from a Lemmy perspective here. Would an instance that doesn’t have down votes be a partial implementation? I don’t think that any system currently running implements all of the Activity Types described in ActivityStreams - you can’t Dislike on Mastodon and the “Travel” event looks like something for a Foursquare clone rather than Lemmy or Mastodon. Surveys look like they could be implemented under the Question type… though I haven’t seen any implement that.
Support for specific extended vocabulary types is expected to vary, with implementations only selecting the extended types and properties that make sense within the specific context and requirements of those applications. However, to avoid possible interoperability issues, implementations must avoid using extension types or properties that unduly overlap with or duplicate the extended vocabulary defined here.
In Activity Streams 2.0, an “extension” is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions must not stop processing or signal an error and must continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined. Accordingly, implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
As much as embrace, extend, extinguish is to be feared, extend is designed into the protocol as being a good thing and allow new structures to be stood up and explored rather than having the spec locked down. The protocol doesn’t care about the motives of the entity that stood up a new instance.
ActivityPub seems to be intended to be extended to allow more and different communities to exist on it.
I am not aware of any system that even attempts to implement the full range of what it offers - events, meetups, restaurant reviews, polling questions, and so on.
Publishers or Consumers implementing Activity Streams as a stream of public data may also want to consider the potential for unsolicited commercial or malicious content and should take preventative measures to recognize such content and either identify it or not include it in their implementations.
Consumers that re-emit ingested content for crawling by search engines should take reasonable measures to limit any use of their site as a Search Engine Optimization loophole. This may include converting untrusted hyperlinks to text or including a rel=“nofollow” attribute.
There are perfectly good reasons to not accept content from Facebook when it starts offering ActivityPub.
Publishers should take reasonable measures to ensure potentially malicious user input such as cross-site scripting attacks are not included in the Activity Streams data they publish.
Defederating because a publisher isn’t taking sufficient measures to ensure that their user input isn’t malicious is a good reason.
However, the “Embrace” and “Extend” parts are what ActivityPub is for and claiming that because Facebook is going to use the protocol and may add additional extended types that aren’t part of the current spec is not a good reason.
Support for specific extended vocabulary types is expected to vary, with implementations only selecting the extended types and properties that make sense within the specific context and requirements of those applications. However, to avoid possible interoperability issues, implementations must avoid using extension types or properties that unduly overlap with or duplicate the extended vocabulary defined here.
In Activity Streams 2.0, an “extension” is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions must not stop processing or signal an error and must continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined. Accordingly, implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
The nature of ActivityPub is such that it is very difficult for content from one site to be made inaccessible on another. You can make it so that content from other sites don’t appear on this site, but restricting content from this site on other sites is difficult.
As I understand it, the only things that defederation will accomplish will be making it so that content from Threads won’t show up in the federated feed and people who want to consume that content will need to go to another site (or Threads itself).
Defederate if Threads is pushing content that isn’t appropriate here. Defederate if the users are behaving badly.
Noting that today is the 10904^th^ day of September, 1993 - I suspect that this will be the case.
Usenet didn’t fail because AOL showed up. It failed because communities had insufficient tools to maintain their identity combined with a new shiny thing (the early web) that made accessing content so much easier (and rich). Defederation is an insufficient tool unless one is willing to become a small archipelago of federated islands that have all be pre-verified as properly administered and ideologically proper to not allow any of the unwashed masses on their shores.
Usenet still exists - though it is a shadow of its former self with a few NNTP servers that federate between each other. It’s administration tools were insufficient to manage the crap that came from the rest of the world resulting in the only way to behave with badly behaved sites was to defederate them… and any sites that federated with them.
The long term survival of ActivityPub is a question of what other tools does a community have to manage the content that appears there other than defederating.
This sounds cool, although I'm pretty sure someone tried it before.
Let's see where this goes!!
「 Extism's goal is simple: make all software programmable. We've released the project under the permissive BSD-3 license, and you can see all of its components on GitHub 」
PSA: Lemmy votes can be manipulated
The best part of the fediverse is that anyone can run their own server. The downside of this is that anyone can easily create hordes of fake accounts, as I will now demonstrate....
Threads and the Fediverse
Start by reading these two articles:...