Notices by marius (mariusor@metalhead.club)

@silverpill the collections have a next property which consumers should follow, no need to mess with the individual query parameters.

@silverpill after={url-encoded-object-id}

@steve apologies, I take "server" in the context of ActivityPub discussion to be an "ActivityPub server", not all the other web-servers involved in the process.

And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

@smallcircles @evan

@steve out of curiousity why do you make a difference between a consumer of AcitvityPub (assumedly you mean something that fetches ActivityPub using HTTP GET) and a C2S client?

My assumption is that if something fetches ActivityPub objects and is capable of rendering it to another representation for its users, that's a client to server client.

Client to server has two sections: consumer and producer and I think anything that fulfills any of those can be called a C2S client...

@smallcircles @evan

@steve yes, but something dumb that only fetches a URL and converts the resulting ActivityPub into a valid other type of representation is a valid client in my opinion. That's what I mean, was that unclear?

@smallcircles @evan

@steve OK, but why?

I feel like I explained my position relatively clearly, I would like to understand yours, even though I feel some animosity has started to crop up.

@smallcircles @evan

@thisismissem it's not explicitly saying to forward authorization, but to me that's implied from "require authentication":

proxyUrl: Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access

https://w3c.github.io/activitypub/#proxyUrl

@evan @benpate @steve @smallcircles

@steve I think
we need to emphasize that timelines can be built from regular collections, even unordered ones, by using some intermediate representations specific to the type of timeline that a client wants to render.

The fact that the specification does not directly support a mapping between a collection and a responsive timeline, *DOES NOT MEAN* one can't be built from it, only that it requires a little more effort on the client side.

My goto example is how rich mail clients allow responsive mailbox representations on top of a much less expressive collection method that IMAP provides compared to ActivityPub.

@smallcircles @evan

@steve yes, that's how I meant it. A client fetches as much of the collection as it can, then applies whatever rules it wants to transform the result into a "timeline" when the user asks for it.

This however most likely requires local caching of the collection to have decent latency.

@smallcircles @evan

@steve frankly I disagree with this point. Servers should be simple. We need to move away from the paradigm of custom purpose ActivityPub servers that Mastodon pushed where the client and server are the same service.

Timelines should be orthogonal to the ActivityPub specification and, in my opinion, kept well away from it.

What's the benefit for my client application to know what your server's preferred timeline representation is?

Let's not go down the path where everything looks like a nail because we really like hammers.

@smallcircles @evan

@silverpill can't wait... the good thing about my implementation of using proxyUrl from the frontend is that it only kicks in on failed requests, so it'll be transparent when you switch.

@silverpill when I fetch mitra actors from the browser with JavaScript fetch, it disallows them due to the server not allowing CORS pre-flight requests.

When I was adding support for Django's C2S client, it became apparent that if we want objects be accessible form in browser clients, the servers need very relaxed CORS policies. I defaulted to accepting all https:// ... but I'm thinking about rules based on the actor's followers perhaps..

I'm thinking in adding #ONI proxyUrl support in the frontend. :goose_hacker:

Currently if a request to a remote #ActivityPub object fails - either due to CORS, or because of authorized fetch - I just display a fallback link to it.

I'm wondering if I can do a two step approach, if the request to the resource fails with 401-403 (for secure fetch) or 400 (for CORS failures) I try to redirect the request through the proxyUrl mechanism.

Only if that fails too, I fallback to something else.

:🎉 ... and done!

Now I have the actors of remote instances (like mitra.social and mastodonapp.uk) loading properly in the inbox of ONI.

I'm not proud of the JavaScript that does it, there must be an idiomatic way to chain fetch requests without the Promise in Promise spaghetti I just wrote. :(

Ooops... mitra.social is down.

I hope it wasn't me that brought it down with my testing. :(( Sorry @silverpill

@pfefferle I added a PKCE task to my todo list:

https://todo.sr.ht/~mariusor/go-activitypub/440

@pfefferle love it! 💗

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.

@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

Just click new post on this page: https://lists.sr.ht/~mariusor/go-activitypub-dev

@pfefferle I changed some stuff to a potential place where this could have happened.

If you can build a new version of BOX, please try again and let me know if it fixes the issue for you.

@manton one way you could do this is by uploading the images, then adding the URLs as attachments, while at the same time they can be linked inline in the text content.

Of course this would be way too much to handle for Mastodon, but from an ActivityPub point of view it makes sense and doesn't require any hand wavy solutions.

In my one user ActivityPub web-app, I have all the moving parts I described above working, but they haven't come together just yet, because the UI for posting is just a CLI tool and it's difficult to describe in markdown an image that hasn't yet been uploaded with a stable URL. But writing this gave me an idea... 🤔

@pfefferle