mastodon - Link to source

What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).

It seems possible... if we can improve the AP C2S API/protocol sufficiently.

#activityPub
in reply to Lutin Discret

mastodon - Link to source

🫧 socialcoding..

@lutindiscret
It depends.. since post-facto interop rules supreme, that's a possible approach to correct course.

social.coop/@smallcircles/1161…

🫧 socialcoding.. (@smallcircles@social.coop)

@reiver@mastodon.social @thisismissem@activitypub.space @mfru@mastodon.social I made a diagram yesterday that contrasts #ActivityPub and #SolidProject that is I think interesting to consider.
🫧 socialcoding.. (social.coop)
@Lutin Discret
in reply to Steve Bate

mastodon - Link to source

Jonathan Frederickson

This is exactly the sort of thing I'm hoping we see on the Fediverse

One thing that might need some careful design is: how to scope down the access that each of the C2S-connected apps have? A game for example doesn't need to be able to read all of my/my friends' messages, only game-related ones

I think the work Spritely's been doing could be a good building block for such a generic server

in reply to Evan Prodromou

mastodon - Link to source

Raphael Lullis

Maybe I am way over my head, but this seems like *exactly* what I am building right now and I'm not really building anything outside of ActivityPub C2S?

I mean... Yes, my current client assumes some specific profile for OAuth and the client will need a proxy to get some data remote servers (to bypass authorized fetch, or to resolve documents from transient activities), but doesn't seem to me that anything I am doing is outside of AP's scope?

This entry was edited (2 days ago)
in reply to Evan Prodromou

mastodon - Link to source

Evan Prodromou

@raphael @silverpill I don't intend to stop working on the ActivityPub API.

There are a lot of us collaborating through the SocialCG ActivityPub API Task Force, and I expect that collaboration to continue:

github.com/swicg/activitypub-a…

GitHub - swicg/activitypub-api: ActivityPub API Task Force repository.

ActivityPub API Task Force repository. Contribute to swicg/activitypub-api development by creating an account on GitHub.
GitHub
@silverpill @Raphael Lullis
in reply to Evan Prodromou

mitra - Link to source

silverpill

I think a generic ActivityPub server can't be built without major changes to ActivityPub. For example, it might be necessary to make all side-effects of activities explicit.

And there is a bigger problem. A generic server without FEP-ef61 is like ATProto PDS or Nostr relay but all data is tied to a single server. This means that it is obsolete before the work has even begun.

in reply to silverpill

mastodon - Link to source

Steve Bate

@silverpill @evan @raphael Several generic AP server implementations have been built, so I don't know what you mean by the side-effect comment. Note that my mental model of a generic server doesn't implement any domain-specific behaviors in the server, but only side-effects specified by AP (and extended generic C2S support). There are also simpler ways to design servers so that content isn't tied to a specific server (with different tradeoffs than FEP-ef61). That's a long discussion...
@Evan Prodromou @silverpill @Raphael Lullis
in reply to Steve Bate

mitra - Link to source

silverpill

A server can't properly process an arbitrary activity without knowing its side effects. A server that only supports a small number of activities mentioned in the ActivityPub spec is obviously not generic.

I can point to other challenges because I've been working on this problem for years, but...

Several generic AP server implementations have been built
There are also simpler ways to design servers so that content isn't tied to a specific server


Wow, for real? I suppose it's time for me to retire then.

in reply to silverpill

mastodon - Link to source

marius

@silverpill I think you're getting confused about ActivityPub side-effects and application logic side-effects.

I call my project FedBOX a "Generic ActivityPub server" because outside of storing ActivityPub objects and activities to a local storage and dispatching said activities to their recipients it doesn't do anything else.

However there's nothing preventing someone from forking the project and adding some other type of logic to it for specific combinations of Activities/Objects. That's the thing I'm trying to do with my GoActivityPub library: take care of the ActivityPub stuff, so you can then do your own stuff alongside it.

@steve @evan @raphael

@Evan Prodromou @silverpill @Raphael Lullis @Steve Bate
This entry was edited (1 day ago)
in reply to silverpill

mastodon - Link to source

Evan Prodromou

@silverpill @mariusor @raphael

I think it's a fair critique and one that we should deal with.

However, I think it's possible to provide value where the server implements side effects of AP core, and not for any other Activity Vocabulary activities or extensions.

With the core AP activities, we can probably give clients most of what they need to implement "side effects" for extensions.

@marius @silverpill @Raphael Lullis
in reply to Evan Prodromou

mastodon - Link to source

Evan Prodromou

@silverpill @mariusor @raphael

For example, let's say we decide that an `Arrive` activity should update the `location` property of the actor.

`Arrive` isn't a core activity in AP. So, instead of expecting the server to change the `location`, the client can send an additional `Update` activity to change the actor's `location` itself.

With CRUD activities and collection activities in core we can get a lot of this done from the client side.

@marius @silverpill @Raphael Lullis
in reply to Evan Prodromou

mastodon - Link to source

Evan Prodromou

@silverpill @mariusor @raphael

I think there's value in having a negotiation between the client and the server so the server can declare its support for side effects for extensions. A way for the server to say, "I'll handle side effects for geosocial applications". Then the client can skip implementing those side effects itself.

@marius @silverpill @Raphael Lullis
in reply to silverpill

mastodon - Link to source

Steve Bate

@silverpill @mariusor @evan @raphael You're starting to get it! 😉 You quoted "extensions" in the previous post and that was good since the way you think of "extensions" is likely very different than my view. The generic servers I'm discussing *are* highly "extensible" (more than most current Fedi implementations).
@Evan Prodromou @marius @silverpill @Raphael Lullis
in reply to silverpill

mastodon - Link to source

marius

@silverpill what are extensions exactly? Are you talking about FEPs that proscribe behaviour alongside structure, or ActivityPub extensions as allowed by JSON-LD.

The FEPs that proscribe behaviour can't ever be done in a "generic" way, and I'm betting you already know that and you're just being facetious.

However the JSON-LD dynamic structure can be reasoned about generically from an ActivityPub point of view using the points I made above: storage to disk, dispatch to recipients.

If you plug smart clients on top of that that have the specific logic you want, you're all the way there to what Steve was talking about.

@steve @evan @raphael

@Evan Prodromou @silverpill @Raphael Lullis @Steve Bate
in reply to marius

mitra - Link to source

silverpill

An extension is a protocol extension. Specifically, I talked about activity types that are not mentioned in ActivityPub.

Here is a side effect of a Like activity:

The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's liked Collection.


Now imagine that you have an EmojiReact activity which server should add to object's emojiReactions collection as a side-effect.

A generic server should be able to do that.

in reply to silverpill

mastodon - Link to source

Raphael Lullis

@silverpill

I'm really not following this logic: you are saying "a generic HTTP server should be able to serve WebDAV requests".

Yes, HTTP servers should be able to serve WebDAV requests, *provided* they implement the extension.

It doesn't mean that they *have* to implement the extension. And an HTTP server that does not support the extension does not make non-HTTP compliant.

@mariusor @steve @evan

@Evan Prodromou @marius @silverpill @Steve Bate
in reply to silverpill

mastodon - Link to source

Raphael Lullis

@silverpill

It is a generic server *because* it is focused only on the ActivityPub API, unlike most of the existing services that interop only with specific APIs (Mastodon's , Lemmy's).

A "generic server", in my view, is one that can take any type of activity posted to a box, and dispatch to the proper targets. The ActivityPub API defines only what to with like/announce/follow. Anything else is up to the application. That's the extensible part.

@mariusor @steve @evan

@Evan Prodromou @marius @silverpill @Steve Bate
in reply to silverpill

mastodon - Link to source

Evan Prodromou

@silverpill @raphael I think that comes down to what you mean by "support".

I think a server that delivers extension activities, or activities with extension properties or extension types as `object` etc , locally or remotely, is "supporting" those types.

Implementing server-side side effects of some extensions may be a bonus, but we can build a lot of great stuff without it.

@silverpill @Raphael Lullis
in reply to Evan Prodromou

mastodon - Link to source

marius

Hey @evan ... I've looked into why I get issues with checkin.swf.pub, and it could be that I'm doing something wrong, but it hits my servers using client_id=checkin.swf.pub/client.jsonld

Which, when gets dereferenced serves an ActivityPub Actor(ish) like document instead of the Client ID Metadata I'm expecting.

I remember I was arguing with Emelia about how to server both formats from the same URL, but in the end I decided it's not worth my time trying to do both, and I'm just expecting the data model described in the RFC7591 Sect2: datatracker.ietf.org/doc/html/…

RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server.
IETF Datatracker
@Evan Prodromou
in reply to Steve Bate

mastodon - Link to source

Ben Pate 🤘🏻

I love this vision. One hurdle I see is the lack of content types + the ability to represent them in HTML.

Bandwagon is my best use case: Albums and Tracks aren’t a standard data type. I could push those into my own AP server, but other servers wouldn’t know how to represent them correctly.

For this to work, we need a restricted subset of HTML for generating previews of unknown content.

This feature exists in oEmbed (optional) but is poorly supported on the Fediverse.

This entry was edited (2 days ago)
in reply to Ben Pate 🤘🏻

mastodon - Link to source

marius

@benpate as long as your custom types have the current ActivityStreams Object as a base (ie, they contain a Content and a MediaType) anyone would be able to render them to some extent.

For cases where you have a different structure, you can have Profile objects alognside them linked to their Preview property. Use the vocabulary to your advantage.

@steve

@Ben Pate 🤘🏻 @Steve Bate
This entry was edited (1 day ago)
in reply to Ben Pate 🤘🏻

mastodon - Link to source

Steve Bate

@benpate The approach I described requires us to think about servers differently. A generic AP server would only store and federate data, and would not render any user-facing content. The C2S clients would know how to render the content because they were coded to do it. Different clients might render the same content very differently for different purposes (although I see value in having the ability to share UI components too).
@Ben Pate 🤘🏻
in reply to Steve Bate

unkn - Link to source

dimkr

FEP-ef61 makes it possible to build a server that only talks to other servers or to a client that pulls inbox (i.e. received activities) and pushes to outbox (outgoing activities). tootik is very close to this, I'm working on a 'local mode' where the server and the UI run locally but synchronize with a server in the internet, a 'dumb pipe' that can send and receive activities.
⇧