If you Announce(Object) are you not following FEP 1b12?
-
@julian It might be because of what FEP-1b12 says in "Implementations" section:
>This document is written based on existing group implementations in Lemmy, Friendica, Hubzilla, Lotide and Peertube. These already federate successfully in production.
Some of these implementations may support Announce(Activity) today, but as far as I know they didn't support it when FEP-1b12 was written
-
Thank you @[email protected] for providing some helpful context.
In that sense, then, it seems as though @[email protected] expected going in that existing implementations would not be strictly compatible with his vision, but one would assume some form of compatibility was reached in spite of this?
That is, Lemmy may expect
Announce(Activity)
, but I bet it also acceptsAnnounce(Object)
if one of their users were to follow a Hubzilla/Friendica group actor... -
[email protected]replied to julian on last edited by [email protected]julian:
Lemmy may expect
Announce(Activity)
, but I bet it also acceptsAnnounce(Object)
if one of their users were to follow a Hubzilla/Friendica group actor...Would it help to add a "Legacy Compatibility"/Postel's Law section explaining this to the FEP itself? As in,
"An implementation MUST produce
Announce(Activity)
messages to conform to this FEP, but it MAY also accept [edit: and/or emit]Announce(Object)
as well for wider compatibility, and if you do, the recommended behavior is... { Normalize | Drop | Translate | etc }"This is helpful to people writing test suites/test-cases because it can give warnings for what an implementation will receive that still help compatibility without giving anyone "Fails" for the core feature
-
-
[email protected]replied to [email protected] on last edited by
Information about Legacy Compatibility was not included on purpose: https://codeberg.org/fediverse/fep/pulls/20#issuecomment-687050But I still think it would be helpful to include. Perhaps in a different FEP, because FEP-1b12 was finalized.
-
@[email protected] I'm not certain whether the variance rises to the level of requiring a separate FEP, since it is essentially just supporting the lack of an activity wrapped around the object in question.
It's unfortunate that finalized FEPs cannot change, since it's essentially just a non-normative description of backward/alternative behaviour.
-
Minor changes are allowed:
A proposal with status
FINAL
can not be changed or updated in a way that would lead to adjustments to implementations.The paragraph proposed by @bumblefudge sounds like a normative change, but not a backward incompatible one, so I wouldn't object against including it.
-
Lemmy only supports
Announce/Activity
, with the exception of sendingAnnounce/Page
for Mastodon compatibility. When I wrote the FEP I wasn't aware that Hubzilla and Friendica sendAnnounce/Object
, otherwise I might have included that. -
Thanks for supplying some additional context @[email protected]
Understanding that, then, would you be open to amending the FEP to include observed behaviour from other implementors who send
Announce(Object)
instead?A second optional pattern would be sending an
Announce(Object)
for increased compatibility with other implementers, though it may be harder to justify amending the FEP for that. -
Yes it would make sense to include
Announce/Object
as a shorthand forAnnounce/Create/Object
. -
As per the discussion generated by this topic, I have updated the NodeBB implementation so that its group actors (NodeBB categories) send out
Announce(Create(Note))
in addition toAnnounce(Note)
, the latter being sent out for compatibility with services that do not handle activity announcement.