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,”
Yes, as co-facilitator of #FEP, that is the point. Highly in favor of a bottom-up 3-phase standards process designed to guarantee an open ecosystem and tech landscape. Wrote a bunch about that on #SocialHub:
Beyond that, even if you think being literal is pedantic: It is practically incorrect
There is no way to guarantee even what we have for any set of systems. To the degree this is true, which it isn't, it is not a characteristic of the fediverse and it is not even a characteristic you can know is being applied in the vast majority of cases.
The latter two points about splitting your timeline and muting just reposts is closer to correct, but is not actually anywhere in the protocol as written. #ActivityPubdoes not include these features. They are useful, but they simply do not exist in AP, and to a greater or lesser extent they have either not been formalized or only barely formalized with a #FEP
This is something we can correct and probably should correct, but we also need to stop telling people it is true of the "fediverse."
Iemand vanuit #Mastodon benadrukt het belang van #OpenStandaarden. Hij roept op dat daar meer financiering voor moet komen om deze door te ontwikkelen. Zeker in het licht van verregaande koppelingen tussen andere sociale media zoals Instagram en Facebook die hier grote budgetten voor hebben.
Ja, dat was ik denk ik, op het #CommonsNetwork event in Den Haag. Enige verwarring daarbij is dat ik niet van Mastodon ben, maar hen indirect wel vertegenwoordig. Ik sta nl. in het algemeel de Fedi voor en haar #OpenStandaarden. O.a. mede-faciliteer en representeer ik al geruime tijd de #SocialHub dev community en het #FEP process beheer.
For those who were not able to attend the technical alignment meeting of the informal "Threadiverse Working Group", I have taken minutes during the meeting and are sharing them here.
Thank you to all those who attended, we will meet again next month! Follow myself or the WG category to be notified about additional developments.
Attendees
Angus McLeod
Julian Lam
Evan Prodromou
Aaron Grey
Rimu Atkinson
Erlend Sogge Heggen
Laurens Hof
Other participants are not listed as they are not mentioned in notes below, but there were ~20 participants.
Notes
Participant introductions
“Forasphere”/”Foraverse” vs “Threadiverse”
Both have a topic-like structure and so much of the technical structure is the same
More helpful to focus on the differences from microblogging as the de facto implementation of ActivityPub
No matter what name, it is mostly UI distinctions with some different handling based on nomenclature
Rimu brings up discussion regarding nomenclature; related document
“We don’t call things the same words”
Aaron posits that “Circles” could be a useful common term
Julian posits that end of the day no implementor here will likely consider changing their already-established terminology
Aaron proposes a goal for the group: determine a common set of terms to use in discussions going forward; a lingua franca
Evan proposes a goal to produce documentation that other forum (or reddit-like alternatives) can use to become compatible
Additional goal (added later): reaching out to other forum devs (who aren’t already in this WG or looking into AP). Additional outreach/engagement from other forum softwares.
Julian suggests that perhaps the FEP process would be a possible path forward
Mastodon’s microblogging concept leads to other implementations following suit
Coordinated effort to increase compatibility between threadiverse-type applications is attractive
Erlend wants to see better interop between threadiverse apps. Discourse to NodeBB, etc.
Angus states that we’ve reached half-way point and summarizes (see above)
Meeting focus shifts to debate re: FEP process or Task force under SocialCG
Julian proposes on behalf of Johannes Ernst (in absentia) that the WG be organized under the FediDevs umbrella
Evan proposes that the WG be an official task force under the SocialCG
W3C/ActivityPub has many task forces already, one for data portability, one for webfinger, one for testing, etc.
Differences between task force report and FEP:
Both similar documents
FEP has a more asynchronous process for clearing out objections, less cohesion than SocialCG
Discussions take place on SocialHub
Most FEPs individually authored
SocialCG reports collaboratively edited and put forth to W3C
Some questions re: FEP process
Evan answers: Anyone can propose, comments collected. After 6 months author can determine it finalized, but implementation varies. Many draft FEPs are dropped due to lack of interest or are hypothetical in nature.
Penar asks whether FEP or W3C report process is faster
Both are roughly equivalent, SocialCG reports are “a few months” to draft, and “a few months” to be accepted/finalized.
Aaron posits that SWICG (or SocialCG) is a better group since it eventually goes into a published W3C article
Aim towards convergence, consistent UI. Safe and usable user experience where the end-user has choice.
Laurens remarks on the increased level of cooperation that has not been often found in the fediverse, sees this as an opportunity to forge a path toward what we want instead of being bound by an FEP.
Angus motions that we join the SWICG as a task force
Motion carries with 12 ayes out of 16 present
Next meeting of SWICG 5 Apr 1pm Eastern; Angus and Julian to attend
3pm Eastern; meeting scheduled end, Evan and Erlend (and some others) drop out
What do we call the group “foraverse” “forasphere” “threadiverse”
Benti posits that it is weird to call ourselves representatives of the threadiverse as that distinction is reserved for Lemmy and nutomic is not present
Julian suggests that the term is not exclusive to Lemmy/kbin and asks to simply expand the definition to include Piefed, Discourse, NodeBB, Flarum, et al.
Additional back and forth regarding how and where to carry on discussions outside of monthly calls
Shared Google Doc sufficient for now, can explore additional options later
Julian posits that a federated option is ideal, acknowledges bias when suggesting that NodeBB be used. However, as it would be federated, where the discussions take place is mostly incidental.
A federated solution would be easiest way to reach fediverse developers.
Angus motions that we call ourselves the Threadiverse Working Group (or Task Force)
Motion carries with 9 ayes out of 13 present
Action Items
Angus or Julian to set up shared Google Doc for meeting/agenda prep for next meeting
Meaning its optional. By no means is it required to discuss there, if you don't want to. For any FEP a forum topic is created, but you can discuss anywhere else.
Each FEP document in the #codeberg repo gets an accompanying tracking issue that list all the places where discussion takes place.
I've implemented basic support for meta groups (groups of groups). There's a lot of redundancy because of the federated nature of the azoriverse, with similar groups duplicated across multiple servers. Meta groups are a solution, by presenting users with a (somewhat transparent) single group that collects all of the posts....
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.
How does this work.. The FEP-f1d5 talks about a node info endpoint, but the FEP states no obligatory endpoint. References lead to an old library that recommends /.well-known/x-nodeinfo2 (for that v2 library). How did a FEP become final without this crucial piece of information or am I simply missing that information in the finalised FEP? #ActivityPub#Fediverse
Currently the #FEP process serves as an instrument for the open ecosystem that allows people to draw attention to what they want to or have built. For reasons of collecting feedback, providing help or in hopes of others adopting their practices so as to increase general interop in some way or other.
The process is informal, lightweight, and its facilitators assume no authority. Anyone can submit FEP's on whatever they want. Authors are in charge, ecosystem decides to adopt or not.
Of course there are numerous ways in which the #FEP process can be improved and further expanded to make it a stronger force towards a broadly interoperable Fediverse. I am a fan of bottom up standards process in 3 stages, where FEP's play a role besides other hives of activity and ultimately evolve open standards, like #ActivityPub.
Getting linked on the mastodon network (tm). A few notes.
A while back, somebody linked to the honk manual. Within one minute, 76 mastodons retrieved the link.
I replied some time later. Within one minute, an additional 58 mastodons fetched the link.
For the day, it amounted to 150 hits, some arriving a bit later. I think not so bad, since it takes me about 200µs to serve this file from cache. It would be more problematic for a larger or more expensive file, however.
There's been some discussion of having the origin provide the preview, and the consequences of fake previews, but I think a reasonable compromise would be to have the origin check if there's a reasonable preview to be had. If the target is not a web page, tune the link so recipients don't try to generate previews.
Also, over the day, 152 hits from Pleroma and 142 from Akkoma, although those numbers are double since every GET is preceded by a HEAD. I'm not sure what happens after the head request, but that could be another way to avoid inflicting unnecessary load.
Give @julian#Github comment some good reactions to show the folks of the #W3C Federated Identity CG that there's more than #BigTech#identity providers to take into account..
Hi Sam. Thanks for your work on the specs. I'm not directly involved with the topic myself but as a technology advocate for #Fediverse / #ActivityPub spreading awareness of the issue. Original article quoted by @julian did that for TBL's Solid project.
On the fedi the story around identity isn't at all clear, other than that most apps implement OAuth2 with client credentials, and some apps offer OIDC facilities 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 🤷
I think I can get the first draft of what I'm thinking for #FeatherPub out in the next… two weeks. It will probably be sans tests for the moment, but my goal is to have a set of gherkin .feature files to go along with it by the time I make significant headway.
For the sake of my own sanity I am not going to develop the logic behind the steps in public (that'll go into my personal project), but I'll at least release the feature files and base spec docs in public.
Just for expectation management: Initially I'm going to put it out as All Rights Reserved, again for my own sanity (basically saying 'no contribs yet'), but this is a temporary measure until I can get my ducks in a row on <various things and permissions>.
Ultimately my current goal is for the side project to be Apache 2, to push the spec as a #FEP (which has a CC-0 license I believe), and to publish the feature files and maybe the underlying test code under one of the more permissive licenses.
Finally figured out why #nodebb posts weren't queryable via Mastodon, turns out it does Content-Type checking, and I was inadvertently breaking #ActivityPub spec by sending in application/json when I should've been sending in "application/activity+json" or 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"'
Latter doesn't play nicely with express, so using the former and all's well!
Full credit to @bouncepaw who gave me key to figuring it out! 🏅
@AltCode That's a good question. At this time I can only try to provide as much linkage and context as I can, and it's up to individual implementors to handle.
In #nodebb's case, each post will have an inReplyTo that points to its direct reply. OP (the root level post) does not have an inReplyTo.
All posts send audience which points to the TOPIC. Each topic (the Page object) sends audience which points to the category.
#FEP 1b12 leaves no room for topic references in replies 🫤
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.
While I’m at it.. I don’t know if #ViralBlocks are a thing or not, but I think they’re worth a look.
Mastodon publishes all my follows.. why not let me publish the trolls I’m muting and blocking, too?
The default setting in #Emissary is to label posts that my friends have blocked, but it’s easy enough to automatically block people that my trusted friends have flagged.
I see an ecosystem.. where tomorrow’s mods publish to many opt-in followers in real time using #ActivityPub, not CSV files.
One thing that I'd be much in favor of is seeing more of the Moderation domain become first-class citizen on the protocol level via ( #FEP'ed ) extensions, rather than something that takes place in informal power structures and fiefdoms by chatter and with a lot of that in non-AP backchannels.
So that governance features and tools stacked on top of that become more well-understood, accessible to anyone, easier to mature, and generally better integrated across the Fediverse.
I'm guessing the "conversation" value in an #ActivityPub Note object is #Mastodon specific, and other implementors have adopted it as a pseudo-standard?
@trwnh Perfect. Yes, this #FEP, while still a draft, looks to be following what I'm looking to accomplish.
I have some concerns over whether "context.audience" would conflict with "audience" as defined in FEP-1b12, but that property is at top-level so I think we might be okay...
While I'm not at the point of making any commitments, I will definitely consider FEP-7888 as I move forward.
@leroy@multiverseofbadness@luceos@nodebb it's not anything #ActivityPub related, it's just an existing HTTP practice. When you call resources via HTTP, one of the headers sent back is Last-Modified or ETag. Something similar would work fine here too.
As it turns out, a lot of #ActivityPub verbs and objects correspond quite nicely with #nodebb verbs and objects (e.g. a like would be an upvote, etc.)
However I'm not exactly sure how the "announce" verb would translate. In #Mastodon, "announce" is a "boost". The closest forum-land equivalent would be the "bump", whereby a topic is brought back to the top of the list (usually through a reply).
Only downside, bumps are reserved for admins. Non-admins "bump" a topic by replying to it.
@leroy nothing so specific, at that point I was only doing a thought experiment at a high level.
I am still working out ideas, but I have been leaning towards broadcasting the "Announce" activity when a local #NodeBB user decides to move a post out of the "federated" topic list and into the local categories.
There is also this #FEP, which I am inclined to follow for the sake of being a team player 😆
meta groups
I've implemented basic support for meta groups (groups of groups). There's a lot of redundancy because of the federated nature of the azoriverse, with similar groups duplicated across multiple servers. Meta groups are a solution, by presenting users with a (somewhat transparent) single group that collects all of the posts....