Piero Bosio Social Web Site Personale

@liaizon I've been in the tech industry for about 20 years and I still have no clue what CEOs are good for...

@mkljczk not enough VC money for integrating that into the website.

@Elizafox or the hitmen from AI companies are about to stumble upon one another at your door...

@stefan what APIs does a server need to implement to be compatible with this? I love the idea, but looks like it's focused on Mastodon and Mastodon likes. :D

@evan yes, that's how I did it too, only in my case the private key of the actor that is authorized by OAuth2 token is used to generate the signature for the proxy fetch. This makes it that servers that implement object ACLs based on the recipients list (which GoActivityPub servers are) are not serving 403s for fetches.

@grumpygamer we'll have to revisit this in 5 to 10 years. :)

@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

@thisismissem which is what proxyUrl is supposed to do, right?

Did you mean it in a different way?

@steve @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 I have just implemented that for the GoActivityPub servers and it's easier than it sounds.

The only important step required is to convert the client authorization token (presumably an OAuth2 bearer token) to a valid actor and then further to a valid Private Key with which to sign the remote request. After that the only thing remaining is to pipe verbatim the received response to the client...

@steve @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 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 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 my reasoning about the ActivityPub client/server model is that the servers form just a just a dumb pipeline to dispatch content from clients to other clients.

When servers are just storage, then everything can be much more flexible. Clients can be as expressive as they want and make whichever assumptions about what "good data" looks like, while servers are just dumb pipes that accept and dispatch everything that's a valid JSON-LD document.

@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

@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 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

@django I would object to FedBOX having "signaled interest or intenent".

FedBOX, and the GoActivityPub library that's been built upon, simply "support" client to server and have been since it's inception 7-8 years ago.

@evan @deadsuperhero

@daniel check out my alt fediverse account https://marius.federated.id

That's a single user ActivityPub server that is used through client to server ActivityPub. It supports short and long form text content, but also image, video and audio. :)

@andycarolan recently I started using my samovar so I get through 4-5 cups of tea by midday. :D

#notcoffee :P