Multiple actually:
"pleroma:fake_object_id"
"pleroma:fakeid"
"pleroma:fakecontext"
and also a "fake" => true
property sometimes.
Furthermore, Create
activities for fetched…
Does the API query error out and if so with what response? Do server-side logs show anything related?
Sorry if my curt comments yesterday ended up sounding harsh; I’m stretched thin on time atm and just quickly pointed out whatever seemed in need of further change
This feels wrong to me. The back-end provides what to show, but how to exactly implement this, is then up to the front-end.
The backend provides safe HTML content to show and frontends just…
From a code-complexity perspective; We now need a way for css to know what posts are mfm and not
If it wasn’t dropped as part of this change we already have that via the .mfm
class. In…
The thing is:
Mastodon emoji listing API does not contain the pack.json data and there’s no good place to add any global metadata…
If media proxy is enabled this should work, otherwise there’s (almost) no introspection into the file content and we rely on the file extensions
Bringing this up with the W3C sounds like the right move. Do you feel like doing this? I can do it if not
It would be great if you could lead this; I’m lacking time atm. But feel free to…
reminder to run mix test
; the function clause mismatches show up there and speaking of mix test
it’d be good to add a test for objects not being fully rejected but still stripped
This now checks for published
in the top-level object, but the code path for activities still passes the top-level activity instead of the child object to check_date
. The activity might not have a published
field and thus crash the process
Instead of duplicating the base function, i’d prefer to lift the logic out into a shared function and pass a flag to it indicating whether or not a full reject is allowed
welp °~°
*(I was trying to figure out if the allowed "empty value" for XML’s xsd:anyURI
JSON-LDs anyURI
range appears to be modeled after allows explicit nulls, but if the spec includes…
we do always fetch the outbox, but activities in it are still cached.
This is insufficent, since:
- it still spams remote servers with many requests *(due to default uniqueness job…
don’t populate it and wait for the next user refresh to occur or Update activity to arrive filling outbox with the correct value
I don't like yet another "fake activity" marker (We already have one) with different semantics. Instead, the fetch logic should be changed to only wrap objects which actually need this