I added a note that relay protocols are not standard AP protocols and are generally not fully conformant with AP.
Fixed, Thanks.
I added a note that there are other variants that may work. It’s interesting, AodeRelay uses /actor in the URI but “relay” as the preferred user name. It’s possible I misinterpreted the Pleroma source and they only require “relay” for the preferred user name and not the URI.
I’d like to transition “FEP-ae0c: Fediverse Relay Protocols: Mastodon and LitePub” to FINAL status (although I’m not exactly sure what that means for Informational FEPs).
/cc @silverpill @helge
Are you sure about the informational status? People are already implementing it: feat: add mastodon style relays by TheNoim · Pull Request #109 · fedify-dev/hollo · GitHub
Yes, I believe it’s informational. It’s documentation of a few existing implementations rather than prescribing future ones. However, given the “implementation” type is mentioned but not defined in the FEP process, I can’t be 100% sure.
It is left to the author’s discretion . We may make “Implementations” section required for proposals of this type, and then create some tooling that extracts information from this section, but there are no plans to add other requirements.
Some of my FEPs are similar to this one, they describe existing implementations, and I intend to assign “implementation” type to them.
What’s the process for moving FEP-ae0c to FINAL? Do I submit a PR with the changes or do the facilitators make those changes?
Could you submit a PR changing the status to FINAL and adding dateFinalized attribute?
Facilitators will merge it.
May I ask why this FEP is finalized? There haven’t been any implementors (except for Fedify, above?) who have submitted comments about this.
I’m attempting to implement Litepub-style relay consumption as per this FEP, and there is no guidance on what state is supposed to be, besides being hardcoded pending when sending the follow, and cancelled when Undoing.
@devnull The state property is not necessary. I send regular Follow and Undo activities, that works.
May I ask why this FEP is finalized? There haven’t been any implementors (except for Fedify, above?) who have submitted comments about this.
There were no objections. FEP process doesn't require implementations, a rough consensus is enough for finalization.
@silverpill @protocol @devnull if the state property isn't defined in any json-ld context won't that make validation fail if anyone bothers to do it?
@sun In the JSON-LD playground, a property that is not defined in @context results in a "blank node". I don't know how bad that is, but at least it doesn't throw an error.
@silverpill @protocol I read more about it and apparently it's never supposed to throw an error because it will just be assumed to be resolveable against the base vocabulary, so it some kind of problem but not a parsing one and can be ignored
I'm putting in notes as I'm attempting to implement a relay subscription following the Litepub-style.
subject as provided by the relay is missing the scheme acct:.yukimochi/Activity-Relay
outbox (https://github.com/yukimochi/Activity-Relay/issues/102)relay.toot.io does not respond to my Follow, and relay.intahnet.co.uk is sending Rejects back. Lightly perusing the issue tracker suggests that this relay utilises manual approval.