Article contains a couple of minor inaccuracies: _misskey_quote doesn't build on FEP-e232, and the other property name is quoteUrl, not quoteURL. But overall it's good and I hope other implementers will notice it.
Hey fedifolks! I was hoping to get some bikeshedding feedback on a new #FEP we're working on at #DistributedPress.
tl;dr we want #ActivityPub objects to link to #P2P URLs for alternate ways to load them. Right now I'm debating between putting them in alsoKnownAs or into the url field. e.g. "alsoKnownAs": ["<ipns://staticpub.mauve.moe>"] for @mauve
I worry that field is already in use and that it could cause trouble. Would a new field name be better? Maybe alternateURL?
We will also be publishing FEPs to ensure that this becomes a standard that can be supported by every ActivityPub implementation.
The #mastodon team just can’t help reinventing features. It’s already a standard any #ActivityPub implementation can support. They could even jump in the discussion forum and work on modifying the existing #FEP If its missing something they need.
Yes, it takes time, but we are a very small team, with only one full-time developer for the backend
It’s wild hearing the largest project on the #fediverse complain about bandwidth/resources. They are, by far, the most well funded organization in the space. Maybe if they stopped ignoring every other implementation and collaborated, it would be a better utilization of their “limited” resources?
Looking at the finalized #FEP 1b12 it seems that there is no explicit definition for what object type a forum topic/thread would fall under. kbin and lemmy both send as:Page which is handled generically by other implementors (as it should). Its omission in the FEP may be completely intentional...
Could send as:OrderedCollection but real-world usage suggests this it's too low-level; worst-case scenario it might get rejected outright 🤷
Please note, this post will be a living document that will be updated over time as new information becomes available.
Over the past several weeks, IFTAS has fielded an increasing number of inquiries about the implications of Threads – the microblogging platform from Instagram, a Meta platform – enabling ActivityPub and testing their connectivity with the Fediverse.
Server admins and moderator teams are grappling with the decision and trying to understand the impact of allowing their service to interact with Threads, and thereby with Meta’s network and data infrastructure.
IFTAS has solicited a list of questions from the community which has been sent to the Threads team. If we get replies, we will post them here. We will continue to collect your questions for the foreseeable future.
IFTAS will remain steadfast in its mission to support the moderators of federated social media services. If a large number of threads.net accounts opt in to federating their content, this would increase both the source of content that may break your terms of service leading to an increase in local reports, as well as the number of accounts able to view your member’s content, leading to an increase in remote reports if your member’s content is deemed objectionable.
Before federating with Threads, you may want to review the Instagram Community Guidelines (Threads is an Instagram product) to review your member content’s applicability. Federating with Threads may expose you to compliance issues you have not previously been concerned with, as Threads is a US corporation with strict compliance requirements regarding subject matter commonly found on the Fediverse, including intellectual property concerns, sexually explicit content, and sex work. Threads users can report any content they find that meets their definition of spam, nudity or sexual activity, hate speech or symbols, violence or dangerous organizations, bullying or harassment, selling illegal or regulated goods, intellectual property violations, suicide or self-injury, eating disorders, scams or fraud, and false information.
According to the GLAAD Social Media Safety Index, Instagram, Thread’s parent, has a 63% SMSI score for safety. While Instagram scores the highest of all the rated platforms, you should note that Instagram will allow accounts on their service that many would choose to block. We are unaware of any shared lists of such accounts on Threads, but if we become aware of such a list we may link to it here. Online hate leads to offline violence which leads to yet more online hate, and all hate and harassment should be reported to the relevant platform, no matter the source.
If you wish to completely shield your members from interacting with Threads, be aware that defederating threads.net stops content coming in, but not necessarily going out. Followers of your members may boost or repost content to their followers, which in turn may be threads.net accounts. Mastodon offers an Authorized Fetch option – Configuring your environment – Mastodon documentation – which will completely remove the ability for Threads to gather content from your service. Other platforms may have similar options, and you should pose this question to the relevant developer team.
You should also be aware of the Threads Supplemental Privacy Policy. This document describes the data Instagram will collect from your users if they interact with Threads, and the intent to service privacy requests, notably:
What information do we collect?
[…]
Information From Third Party Services and Users: We collect information about the Third Party Services and Third Party Users who interact with Threads. If you interact with Threads through a Third Party Service (such as by following Threads users, interacting with Threads content, or by allowing Threads users to follow you or interact with your content), we collect information about your third-party account and profile (such as your username, profile picture, and the name and IP address of the Third Party Service on which you are registered), your content (such as when you allow Threads users to follow, like, reshare, or have mentions in your posts), and your interactions (such as when you follow, like, reshare, or have mentions in Threads posts).
(IFTAS note, this is the same information most ActivityPub servers will collect if a user interacts)
and:
How can you manage or delete your information and exercise your rights?
[…]
If you are a Third Party User, our ability to verify your request may be limited and we may be unable to process your request. Please note, however, that the interoperable protocol allows Third Party Services to automatically send Threads requests for deletion of individual posts when those posts are deleted on the Third Party Service. We make reasonable efforts to honor such requests when we receive them. Contact your Third Party Service to learn more.
Below are the initial set of questions submitted to the Threads team, as we learn more, we will update this page.
Questions
If a Fediverse user reports content from threads.net to their service provider and chooses to notify the source server, how does Threads receive it? Can Threads receive it?
If a Threads user reports content from a third party to Threads Trust and Safety, is that report forwarded to the third party moderation workflow?
How will Threads observe and effect user-to-user blocks that involve a third party?
If a third party service publicly defederates Threads in a fashion Threads can discern, will Threads reflect that defederation and not ingest posts or profiles from that service?
Will Threads take an “allowlist” approach, only federating with approved instances; or a “denylist” approach, federating with all instances by default unless they are explicitly blocked? Will any such lists – if they exist – be public?
How will Threads safeguard against federating with known bad actors in the existing ActivityPub space, thereby exposing Threads users to accounts and servers that are widely defederated by the community at large?
Will Threads require instances that federate with it to adhere to Threads-defined moderation standards? If yes, will Threads publish these standards?
Followed-up to my 3-months old proposal for a bottom-up 3-stage Standards Process to guarantee a decentralized and open ecosystem. A process that goes:
This has urgency, or corporate takeover is assured!
“Any decentralized [ecosystem] requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system.”
Just read about your intent to elaborate a bit on some of the #FediverseIdea issues. Would be wonderful, and most welcome.
The repository is under the #Fediverse org on Codeberg, where also the #FEP can be found, and fedi delightful lists I maintain (published to https://delightful.club ).
I am looking for a few people who would be willing to review my (WIP) JSON-LD Reduced #FEP.
It's a little rough right now, but really I need to get others eyes on it if I am going to make any progress on it and I've been sitting on it long enough.
The basic goal is to make it so that you can use JSON-LD's context as a list of extensions and reduce the processing complexity, without actually breaking anyone who chooses to adopt it.
In my week off I had intended to work on my #JsonLD#FEP, but my body had other plans on one front and the internet had other plans on another front, so here we are.
#FEP#AE97 is interesting, but while it makes possible open relays (in the #SMTP-relay sense) obviating the dependency on much static infrastructure for message emission, reception remains a problem.
Considering writing an #FEP that allows using #IndieAuth logins as display handles. The basic idea is that next to the meta tags/headers for OAuth links, you'd have a public key that can be used to verify a signature placed in a field in an AP Actor object. There would be another field next to the signature that tells remote servers what the preferred handle is. If lookup succeeds and the signature is valid, show the handle (possibly simplified) next to an IndieAuth icon.
Idle thought — what happens when a server is temporarily down? According to #ActivityPub spec, sending instances should re-deliver:
> For federated servers performing delivery to a third party server, delivery SHOULD be performed asynchronously, and SHOULD additionally retry delivery to recipients if it fails due to network error.
Deliberately vague by design, I wonder if there's an #fep that specifies something more, e.g. exponential backoff, batching, when to give up, etc.
Since the lemmy issue is getting overrun with people talking about other proposals, I'm thinking about submitting this as a #FEP. Is that still a useful process? I don't know how many projects look to FEPs for implementation guidance.
At the #SocialHub developer community that evolves the #Fediverse and the #ActivityStreams / #ActivityPub open standards we are thinking of using #Gherkin and #BDD test suites to formally define the expected behaviour of the protocol and AP vocabulary extensions that various apps use.
Among others this will be part of Fediverse Enhancement Proposals or #FEP's. See:
I might point to fediverse-ideas repository here, a recently started initiative in the same #Codeberg organization where the #ActivityPub#FEP's are too.
The #FEP is a good grassroots initiative, that is "névé" and troubling as it lacks "meaning" and is running as a "hobby" project with little if any social buy in.
NOTE: no amount of technical thinking/tinkering will add "meaning" as this is a social, not a technical problem.
"A proxy object is an [ActivityPub] object that is semantically identical to an entity on another, non-ActivityPub protocol. For example, an ActivityPub-to-Nostr bridge creates Actors and Notes that are proxies for Nostr users and notes."
Today's question for a resilient #Fediverse is whether various different initiatives are willing to collaborate and cross-pollinate, while keeping their independence.
There's great opportunity to increase the cohesion of the #GrassrootsFedi#ActivityPub developer community and creating strong joins:
deleted_by_author