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.
@silverpill i have received your like and it was relayed from here to my other contacts. The fact that other hubs may reject them with 409 is because they are supposed to receive the like relayed from my channel in case they are accepted here.
@hrefna I think my preference would go to 1) for starters. Better than 3) because there you have to click the 'aggregate FEP' to discover the constituent parts. A more elaborate future FEP process might then support 2) as well.
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 🤷
@devnull@AltCode this is why i don’t particularly like 1b12 actually — it’s got too many app-specific interpretations implicitly baked into it. doesn’t strike me as particularly intentional. i’d still use a Collection of some type to represent a thread, and i’d make it available via as:context instead of as:audience. context is a “grouping of relevant objects” property whereas audience is a sort of “keep these people in the loop” property. impls should adapt to proper usage rather than reverse.
@trwnh I also found the decision to use as:audience to be questionable, since it is included in AP spec under delivery (section 7.1) as potentially addressable.
I'm happy to use as:context, as long as it doesn't conflict with any current usages of the property. To adhere to 1b12 I can continue to use as:audience to point to the category.
This can be anything. There are a couple of labels in the issue tracker. Some ideas may be candidate to become #FEP's while others are best marked 'Vague' and just seeds to brainstorm on some more.
From my previous notes docs I have pared it down to a minimal subset that maintains the flexibility. There's too much flexibility in several ways, but hopefully I've also constrained how to do it in such a way that it's still broadly interoperable and more specific specifications can be tested.
@hrefna If this had been around when I started working on #ActivityPub / #FediDev stuff, it would probably feature heavily in my automated test setup by now.
It might take a bit more standardisation work to reap the benefits, though, such as specifying the result in more detail (out of scope for this proposal, I know).
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.
@hrefna Do you need knowledgeable people, or do you also want reviewing for accessibility for people who don't know the subject well? I can help on the latter!
(Docs that assume significant prior knowledge are fine, I just don't know if this doc is supposed to be in that category or not.)
@sgf Maybe in a second round ^^ That sort of feedback is almost certainly useful, but in the first round things are a bit rough and prior context may be more important.
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.