I'm pretty sure that would not be in Meta's best interest, from their point of view. After all, Meta is all about harvesting your personal data. I believe whether to federate or not will come down to how egregious the federation terms are that Meta will propose because you know they will want to access user data in some fashion for their own profit. If they want the same kind of data from the Fediverse as they get from their native app, the answer will be a resounding "no". If they ask for even 20% of that data, the answer will remain the same.
this post was submitted on 08 Jul 2023
1 points (100.0% liked)
Fediverse
28418 readers
795 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
If things played out in just the right way, this could push them away from the Fediverse entirely, I'd think. Seems it would be hard to monetize any traffic coming from the Fediverse end of things, which would make the whole thing more of a headache than it's worth for them.
An instance that was explicitly set up as a read-only backdoor to Threads probably wouldn't stay federated long, but is a cool idea at least.
Yes, and that's likely why Threads uses ActivityPub to begin with. See the EU's Digital Markets Act: https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en
Examples of the “do’s” - Gatekeeper platforms will have to:
- allow third parties to inter-operate with the gatekeeper’s own services in certain specific situations
- allow their business users to access the data that they generate in their use of the gatekeeper’s platform
- provide companies advertising on their platform with the tools and information necessary for advertisers and publishers to carry out their own independent verification of their advertisements hosted by the gatekeeper
- allow their business users to promote their offer and conclude contracts with their customers outside the gatekeeper’s platform
The interoperability is the big one. Being federated means that Threads isn't considered a "gatekeeper platform". I wouldn't be surprised if Instagram and maybe even Facebook itself start to federate as well. Since Threads isn't currently connected to the wider fediverse, that's probably why they're not in the EU yet.
This also means that fears of "Embrace, Extend, Extinguish" are likely overblown. Breaking fediverse interoperability means that they'd be a gatekeeper again and subject to EU regulations against gatekeepers. The whole reason why Facebook is making Threads ActivityPub is so they don't get hit by EU rules about being gatekeepers of content.
This means your normal fediverse apps (e.g. Fedilab) would be able to work with Threads natively, without any need for "read-only" instances like you say.
Does this also apply to Twitter? The EU regulations could be the only way to get projects like Nitter back.
Yes. Here are the timelines:
The DMA started applying as of beginning of May 2023. Within two months, companies providing core platform services have to notify the Commission and provide all relevant information. The Commission will then have 45 working days to adopt a decision designating a specific gatekeeper. Designated gatekeepers will have six months after the Commission decision to ensure compliance with the obligations foreseen in the DMA.
So we should start hearing things in about 2-3 months, with compliance in 8-9 months.
Relevant sections:
The ability of end users to acquire content, subscriptions, features or other items outside the core platform services of the gatekeeper should not be undermined or restricted. In particular, a situation should be avoided whereby gatekeepers restrict end users from access to, and use of, such services via a software application running on their core platform service. For example, subscribers to online content purchased outside a software application, software application store or virtual assistant should not be prevented from accessing such online content on a software application on the core platform service of the gatekeeper simply because it was purchased outside such software application, software application store or virtual assistant.
Gatekeepers can hamper the ability of end users to access online content and services, including software applications. Therefore, rules should be established to ensure that the rights of end users to access an open internet are not compromised by the conduct of gatekeepers. Gatekeepers can also technically limit the ability of end users to effectively switch between different undertakings providing internet access service, in particular through their control over hardware or operating systems. This distorts the level playing field for internet access services and ultimately harms end users. It should therefore be ensured that gatekeepers do not unduly restrict end users in choosing the undertaking providing their internet access service.
The lack of interoperability allows gatekeepers that provide number-independent interpersonal communications services to benefit from strong network effects, which contributes to the weakening of contestability. Furthermore, regardless of whether end users ‘multi-home’, gatekeepers often provide number-independent interpersonal communications services as part of their platform ecosystem, and this further exacerbates entry barriers for alternative providers of such services and increases costs for end users to switch. Without prejudice to Directive (EU) 2018/1972 of the European Parliament and of the Council (14) and, in particular, the conditions and procedures laid down in Article 61 thereof, gatekeepers should therefore ensure, free of charge and upon request, interoperability with certain basic functionalities of their number-independent interpersonal communications services that they provide to their own end users, to third-party providers of such services.
Gatekeepers should ensure interoperability for third-party providers of number-independent interpersonal communications services that offer or intend to offer their number-independent interpersonal communications services to end users and business users in the Union. To facilitate the practical implementation of such interoperability, the gatekeeper concerned should be required to publish a reference offer laying down the technical details and general terms and conditions of interoperability with its number-independent interpersonal communications services. It should be possible for the Commission, if applicable, to consult the Body of European Regulators for Electronic Communications, in order to determine whether the technical details and the general terms and conditions published in the reference offer that the gatekeeper intends to implement or has implemented ensures compliance with this obligation.
In all cases, the gatekeeper and the requesting provider should ensure that interoperability does not undermine a high level of security and data protection in line with their obligations laid down in this Regulation and applicable Union law, in particular Regulation (EU) 2016/679 and Directive 2002/58/EC. The obligation related to interoperability should be without prejudice to the information and choices to be made available to end users of the number-independent interpersonal communication services of the gatekeeper and the requesting provider under this Regulation and other Union law, in particular Regulation (EU) 2016/679.
Pretty clear legislation - no lock-in, don't block access to content, you must publish your API for others to use. Very good legislation.