Treating ActivityPub messages as plain JSON undermines extensibility because it prevents the use of JSON-LD features like context definitions, leading to potential property name collisions and making it difficult for implementations to reliably interpret or extend messages.
No, treating ActivityPub as JSON doesn't undermine extensibility. ActivityPub is extended by adding new properties to JSON objects, and if you want to avoid collisions you can use URLs or reverse-DNS strings for property names. JSON-LD is not needed for that, it only complicates things for no reason.
@steve Why would I send an expanded toot: URI when all servers expect a short name? Your example is another proof that JSON-LD is only useful for solving problems created by JSON-LD.
@silverpill Those workarounds for the undermined extensibility don't negate my point and will not generally interoperate. According to the ActivityPub book, "One point to note is that correctly parsing and interacting with AS2 objects with extended properties requires a JSON-LD-aware parser." I agree this isn't absolutely true (in special cases) but try sending expanded "toot" context term URIs and see how well it works 😉 (since all servers AFAIK expect those terms to be compacted).
@steve Is there code somewhere for Flowz? At least Pleroma has AP C2S so probably could be another choice of client (only one I know with AP C2S being AndStatus).
@steve@silverpill alright. I found it basically impossible to store and index efficiently for common access patterns and gave up and just went back to treating it as json. I tried a few triple store databases and the performance wasn't great for my historic dataset. I'll try it again someday though
Right, so what is your suggestion? To force all application developers to conform to one unique schema, or to come up with an ad-hoc, bug ridden re-implementation of namespaces on top of plain JSON?
@pfefferle also perhaps @django will be interested in collaborating. He's the latest to try to implement clients for C2S, and I imagine WordPress would be a sweet, sweet target for him.
@pfefferle I haven't been working on Flowz for the last 6 or 7 months, but I plan to dust it off and continue work on it given the recent interest in the ActivityPub client API. I subscribed to the github issue and will track that. Is the WP implementation ready for testing?
(I am not very familiar with go, so please don't blame me if what I say is totally wrong)
I think box is checking for an Actor object and if it finds only a URI, it simply assumes that the Outbox is `{profile-id}/outbox` instead of checking for the real outbox URL!?
@pfefferle that should already be the case. How does the accept header look like for you on the server? I'll double check tomorrow if I'm doing something stupid and haven't noticed until now. :D
@pfefferle yes, that might be possible. BOX is strongly biased with the conventions of GoActivitPub where actorIRI/outbox is most of the time a safe assumption to make.
But there are mechanisms to dereference the oubox correctly after loading an Actor object, and usually I default to that, the "just append outbox to the URL" logic is a last resort.
Do you think you can send an email to the GoActivityPub mailing list with details about your issue, so I can try to find where exactly this happens? TY
GoActivityPub doesn't really do "scopes" because I couldn't think of a way store the permissions on the server side in a way that doesn't require custom logic to interact with vanilla ActivityPub objects.