-

2026-03-13 22:24:56

silverpill@mitra.social

@reiver Hey, I just found this:

https://github.com/reiver/vibefed/blob/master/skills/kb-fediverse-portable-objects/SKILL.md

In general, I am not opposed to such project. If these "skills" could improve LLM output, that's great.

However, the input document itself appears to be generated, and contains numerous inaccuracies. To name a few:

- It mentions did:ap, which was replaced with 'ap' URis long time ago .
- It says that FEP-c390 is required to bridge regular AP and portable AP. But FEP-ef61 supports compatible identifiers, and is entirely independent of FEP-c390.

I don't know if this is a serious project. If you're interested in improving it, we can talk about that, but in its current state it is completely useless.

2026-03-13 22:31:22

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

@silverpill

I do want to improve it.

...

To create a plugin for that LLM coding tool, I took regular text, and got the LLM to re-structure the text in a way that it can use

It is sort of like "compiling" it

Sometimes I fed it something I wrote. (The HTTP signature stuff is based on a document I wrote. Basically, from my notes when I implemented HTTP signatures)

But, for FEP related stuff I just fed it the FEP. But, it searches the web sometimes

I haven't gone and re-checked things yet

2026-03-13 22:32:28

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

@silverpill

If you have any other feedback, I would welcome it.

2026-03-13 23:07:19

silverpill

silverpill@mitra.social

@reiver It pulls text from FEP-ef61 discussion thread in a seemingly random way. Maybe the result could be improved by telling it to read only FEPs and https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md ?

I do have more feedback, but I will wait until the aforementioned issues are addressed.

2026-03-14 02:01:07

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

@silverpill

I gave it this prompt:

"""

Act as a skeptical fact-checker.
Your goal is to find errors in a document I will share with you.
For every significant assertion, look for counter-evidence or nuances that the text might have missed.
If a statement is an oversimplification, flag it.

There is a document here:
"skills/kb-fediverse-portable-objects/SKILL.md"

"""

These are the results it gave me....

2026-03-14 02:05:14

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

1. OVERSIMPLIFICATION: "The existing Move activity only migrates followers" (line 30) This is an oversimplification. The Move activity itself only automatically migrates followers (forces unfollow + refollow). But Mastodon's full migration process also <br />supports exporting and importing follows, bookmarks, lists, mutes, blocks, and domain blocks via CSV files. The document makes it sound like followers are the only thing that survives — in practice, most social graph data can be transferred, just not <br />automatically via the protocol. Posts and media are what truly cannot be migrated. The sentence should distinguish between what Move does at the protocol level vs. what Mastodon's migration workflow supports. Source: <br />https://docs.joinmastodon.org/user/moving/

@silverpill

2026-03-14 02:06:53

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

@silverpill

"""
2. ERROR: LOLA is called "Linked Open Local Authority" (line 386)

LOLA actually stands for "Live Online Account" portability — not "Linked Open Local Authority." This is a factual error.

Source: https://swicg.github.io/activitypub-data-portability/lola
"""

2026-03-14 02:12:21

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

3. OVERSIMPLIFICATION: "LOLA is a separate specification from the W3C Social Web Incubator Community Group" (lines 388-389) LOLA originated from the Data Portability Task Force within the SWICG (Social Web Incubator Community Group). The new W3C Social <br />Web Working Group charter lists LOLA as a potential Rec-track deliverable. Calling it "a separate specification from" the CG is misleading — it was produced by the CG's task force and may be adopted by the new WG. Source: <br />https://www.w3.org/2026/01/social-web-wg-charter.html

@silverpill

2026-03-14 02:14:30

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

4. QUESTIONABLE: FEP-fe34 listed as "(unnamed)" (line 327) The document says FEP-fe34 | (unnamed) | Origin-based security model. FEP-fe34 does have a name: "Origin-based security model". The document uses that name elsewhere (section title at line 199), <br />but then contradicts itself by listing it as "(unnamed)" in the table. This is an internal inconsistency. Source: https://socialhub.activitypub.rocks/t/fep-fe34-origin-based-security-model/4292

@silverpill

2026-03-14 02:17:52

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

5. UNVERIFIABLE: "Forte" and "tootik" implementations (lines 368-369) The implementation matrix lists Forte and tootik as implementations with detail level "Noted" / "Listed as implementation." I could not find independent confirmation of Forte or tootik <br />implementing FEP-ef61. The SocialHub discussion thread for FEP-ef61 contains no documented implementations. These entries may come from the FEP document's own implementations section (which couldn't be fetched due to Codeberg's bot protection), but <br />claiming them without verification is risky — FEP implementation sections are often aspirational or partial.

@silverpill

2026-03-14 02:20:35

@reiver ⊼ (Charles) :batman:

reiver@mastodon.social

6. NUANCE MISSING: did:ap:key debate (lines 100-102) The document says bumblefudge argued nesting DIDs "breaks the spirit" of the DID specification and silverpill "defended it as a legitimate resolution algorithm that the spec doesn't prohibit." This is a <br />fair summary but misses a key nuance: bumblefudge also suggested an alternative (ap://did:example as a URI scheme wrapping DIDs, rather than composing DID methods). This alternative would have avoided the DID-within-DID controversy entirely. The omission <br />makes the debate sound like a simple disagree-and-defend, when there was a concrete counter-proposal. Source: https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738

@silverpill

2026-03-14 23:37:48

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@@reiver ⊼ (Charles) :batman: @silverpill This is simply because little is written about Forte on the Web.

However, I was there when Forte was born back in September, 2024. I was on (streams) back then. Mike Macgirvin had implemented FEP-ef61 in the "nomad" branch of the streams repository a few months ago to test it. When he was confident enough, he merged the "nomad" branch into the regular "dev" branch. In July, 2024, he merged the "dev" branch into the "release" branch, causing the FEP-ef61 implementation to be rolled out to daily-driver (streams) servers.

However, it was a maze of Nomad and Zot6 and non-nomadic ActivityPub and FEP-ef61 identities for everything that boiled over. (streams) wouldn't federate with anything anymore, not even with itself. My two still existing (streams) channels, @Jupiter Rowland's (streams) outlet and @Jupiter's Fedi-Memes on (streams), were both affected by this. They were amongst the very first (streams) channels created on an account with FEP-ef61 DID support.

Mike would spend half of the summer trying to figure out what had happened and how to fix it. Even while (streams) was still broken, Forte was born in August, 2024 when Mike forked the streams repository and ripped all traces of Nomad and Zot6 support out, probably also in order to get rid of the corresponding IDs and facilitate debugging.

This means that FEP-ef61, which had literally caused this whole mayhem and which has to be considered responsible for Forte's very existence, was a) implemented in the streams repository when it was forked into Forte and b) not removed from Forte post-fork. It would not have made any sense to remove FEP-ef61 when one reason why Forte was made at that point in history was in order to debug FEP-ef61.

Sidenotes: Mike managed to fix (streams). This whole issue burned him out so much that he officially quit developing Fediverse software, effective September 1st, 2024, midnight. He still carries on working on both (streams) and Forte because nobody else does, what with how many people even use them.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #FEP_ef61