@silverpill @technical-discussion Yes, fep-1b12 moderators could be authorised actors.Yes 'invite-actor' refers to InviteCode.attributedTo. I agree this isn't very clear...I'll update the FEP soon with your feedback, thank you
@trwnh @julian @mooooooo it's also crappy for caching. Using a standalone document for the key lets you set a far-future expiry header, `Cache-Control: max-age=315360000`. So, clients never need to refetch. If you want to rotate the key, you give a new ID with a new URL.
@mooooooo It probably refers to HTTP signature algorithmBtw I wrote a guide that explains how to do AP: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md
@benpate thinking out loud, we don't need proofs to do this, they just guarantee that the object the proof is attached to hasn't been modified in transit.
What you need is a checksum! sha256 hash with each Endorsement object. Maybe that hash forms part of the id itself, then you don't need a property.
Not sure who's going to yell at me for that one.
@julian@activitypub.space @gabboman@gabboman.xyz @jcm@wafrn.jcm.re Aktor, my first attempt of Writing a AP instance, is using a Tumblr Like UI, and does exactly this... it is possible.
Slowly developing the in depth testing of the same functionality at different levels in the #GoActivityPub stack. I have just finished the collection pagination integration test as exposed in the reference server implementation for the library. So we now have the same pagination functionality covered in unit-tests in the different storage backends, also covered by the storage conformance suite, and now, through an integration test in the server application itself.#ActivityPub #ActivitypubDev #fedidev
@toddsundsted eh... for an admin interface it has a better UX than having to ssh to a machine where the service is already running and deal with executing commands in a container or whatnot, but for actual end-users it's probably far from ideal.
@julian This is where I'd (politely) disagree. "The UX" is often baked into the API, it's not a "simple dialog box you slap on top". I agree there are lots of different directions it can go but if we realize we need something ELSE in the API to make the "scoring" work, we don't want to find that out after it's too late.@GavinChait @benpate @ramsey
> @scottjenson@social.coop said in Tagging those who contributed to the `Endorse` activity design. Here's an update:
>
> So the real question is how do we rollup these various signals and present them to the user?
Personally I would leave this part out of any standard you write because a lot of it falls under "implementation details" which you can punt elsewhere
@gavinchait@wandering.shop @benpate@mastodon.social @scottjenson@social.coop @ramsey@phpc.social
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.
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.
Except not in this edge case
