7888 doesn't lay claim to context, additional uses are encouraged, even
Suggest downgrading requirement of proof to MAY. Upgrade it to MUST in a new FEP. Some of us have no immediate plans to support object integrity proofs. Especially since an endorsement is resolvable, there's no need for a proof — t'is merely a convenience.
@phnt@fluffytail.org considering the Endorse (or Endorsement) object needs to be resolved anyways as it contains potentially relevant metadata, it seems the "save network requests" argument is moot.
It's not especially hard to add new activity handlers in NodeBB, it's just a personal preference.
@phnt@fluffytail.org yeah but I'm also saying you don't need JSON-LD to adequately distinguish between embedded objects. People have been doing it for decades already. No pseudo-namespaces, no JSON-LD
We're already derailing from the main topic at hand :stuck_out_tongue_winking_eye: perhaps we can both agree JSON-LD is pointless and move on.
> @silverpill@mitra.socialsaid:
>
> And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).
I agree with this. Offer(Endorsement) sounds better.
@phnt@fluffytail.org@silverpill@mitra.social look, I'm against JSON-LD as much as the next guy, but isn't that the whole point of JSON-LD — so you don't have to do these contrived naming shenanigans‽
C's reply didn't get dropped, it simply didn't include A, the original server. The last reply did, but because the context was A, it never contained it, so it never pulled it. inReplyTo isn't checked when utilising context-backfill because it is supposed to replace having to do that.
I'm not sure which case it was, but #1 definitely applies in many cases where older Mastodon servers don't report a context. I am also not sure whether Mastodon implements context inheritance as described in FEP 11dd
#2 does apply if the mention were explicitly removed (in the case of Mastodon). Most other software doesn't tend to pre-fill a bunch of mentions since other addressing techniques are used.
> @julian@fietkau.socialsaid:
>
> Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting.
... but it is great that you posted it! You've shared a common use-case for a webfinger resolution to a different domain... what @julian@fietkau.social calls the split-domain.
So in that case, a blanket rejection of a different domain isn't the right approach.
Correct. It's intentional to keep users and communities unique since webfinger, the identification protocol used by AP, is understood to refer to one user at a time (although it doesn't preclude it from sending multiple, which it does in the case of Lemmy.)
Lemmy will prioritize users over communities, which means you can essentially render a community unfindable if you make a user account of the same name. Oops!
Two thoughts:
7888 doesn't lay claim to
context, additional uses are encouraged, evenSuggest downgrading requirement of proof to MAY. Upgrade it to MUST in a new FEP. Some of us have no immediate plans to support object integrity proofs. Especially since an endorsement is resolvable, there's no need for a proof — t'is merely a convenience.
@benpate could Endorsement types be split off into a separate FEP? I think keeping things simple makes it easier for potential devs to digest.
@benpate I still agree with @silverpill@mitra.social that Endorsement makes more sense because it's metadata can be updated (content, tags, etc.)
Like, block, etc. don't have that additional concern AFAIK. However it's not a sticking point for me and I am ok with whatever.
Do you mean this API endpoint?
https://docs.joinmastodon.org/methods/endorsements/
It's not AP, so it's not conflicting with this FEP, no?
TIL Mastodon has endorsements.
@phnt@fluffytail.org considering the Endorse (or Endorsement) object needs to be resolved anyways as it contains potentially relevant metadata, it seems the "save network requests" argument is moot.
It's not especially hard to add new activity handlers in NodeBB, it's just a personal preference.
@phnt@fluffytail.org yeah but I'm also saying you don't need JSON-LD to adequately distinguish between embedded objects. People have been doing it for decades already. No pseudo-namespaces, no JSON-LD
We're already derailing from the main topic at hand :stuck_out_tongue_winking_eye: perhaps we can both agree JSON-LD is pointless and move on.
> @silverpill@mitra.social said: > > And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).
I agree with this.
Offer(Endorsement)sounds better.@phnt@fluffytail.org @silverpill@mitra.social look, I'm against JSON-LD as much as the next guy, but isn't that the whole point of JSON-LD — so you don't have to do these contrived naming shenanigans‽
> As it stands now, Accept, Reject and Undo are identical to activities related to a follow relationship.
I disagree, I think using existing vocabulary is superior. You probably already distinguish your logic paths based on the object.
In fact, that this FEP uses a scheme similar to existing Follow relationships makes it easier to adopt.
Ben, I'd even put in a blurb to make note of the similarities, and how they're intentional.
C's reply didn't get dropped, it simply didn't includeA, the original server. The last reply did, but because the context wasA, it never contained it, so it never pulled it.inReplyToisn't checked when utilising context-backfill because it is supposed to replace having to do that.Except not in this edge case :)
I'm not sure which case it was, but #1 definitely applies in many cases where older Mastodon servers don't report a
context. I am also not sure whether Mastodon implements context inheritance as described in FEP 11dd#2 does apply if the mention were explicitly removed (in the case of Mastodon). Most other software doesn't tend to pre-fill a bunch of mentions since other addressing techniques are used.
A million and one people said they'd leave Reddit if
old.got shut down. Let's see if they come.@julian@fietkau.social yes I agree, I think this would work too. The hard part is having the Webfinger endpoint set up on the other hostname.
It's a bit technical for just anybody to do it, but I could conceivably see a simple nginx config set up to serve just one record.....
> @julian@fietkau.social said: > > Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting.
oooooooooh, now you have my attention.
@julian@fietkau.social thanks for summarizing the split domain dance for me.
Assuming this is how your canary is set up?
@evan@cosocial.ca boy, that second half does a bit of heavy lifting doesn't it :smirk_cat:
@julian@fietkau.social the only way I can think of it conceivably working is if Webfinger(domain A) » Account (domain B) »
name: user@domainASo, a two-way back-reference.
... but it is great that you posted it! You've shared a common use-case for a webfinger resolution to a different domain... what @julian@fietkau.social calls the split-domain.
So in that case, a blanket rejection of a different domain isn't the right approach.
@wronglang@bayes.club actually, no! That's a different Julian: @julian@fietkau.social :laughing:
But it seems we have thought about the same problem.
Correct. It's intentional to keep users and communities unique since webfinger, the identification protocol used by AP, is understood to refer to one user at a time (although it doesn't preclude it from sending multiple, which it does in the case of Lemmy.)
Lemmy will prioritize users over communities, which means you can essentially render a community unfindable if you make a user account of the same name. Oops!
Or maybe it's the other way around, I forget.