What if...
-
I can't wait to see what you build! Good luck.
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?
-
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.
@steve I've built the server part already, that was 5 years ago. Still waiting for people with the skills to build the UIs though...
-
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?
@raphael @silverpill @steve I also think that Steve's vision is realisable with ActivityPub API, although I think adding optional features like search, server push and so on makes it easier.
-
@raphael @silverpill @steve I also think that Steve's vision is realisable with ActivityPub API, although I think adding optional features like search, server push and so on makes it easier.
Silverpill does not agree with us. I am wishing Silverpill well in their plan to rebuild with a completely different ground-up API. Silverpill is skilled and smart and very familiar with ActivityPub in great detail, so I'm sure they will come up with some interesting API architecture.
-
Silverpill does not agree with us. I am wishing Silverpill well in their plan to rebuild with a completely different ground-up API. Silverpill is skilled and smart and very familiar with ActivityPub in great detail, so I'm sure they will come up with some interesting API architecture.
@raphael @silverpill @steve 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 - 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 (github.com)
-
@steve I've built the server part already, that was 5 years ago. Still waiting for people with the skills to build the UIs though...
@mariusor @steve Does your server work with https://checkin.swf.pub/ ? Or https://github.com/evanp/ap ?
-
@mariusor @steve Does your server work with https://checkin.swf.pub/ ? Or https://github.com/evanp/ap ?
-
@mariusor @steve Does your server work with https://checkin.swf.pub/ ? Or https://github.com/evanp/ap ?
@evan @mariusor @steve oh neat!
Add Arrive outbox handler for check-in activities by pfefferle · Pull Request #2977 · Automattic/wordpress-activitypub
ActivityPub for WordPress. Contribute to Automattic/wordpress-activitypub development by creating an account on GitHub.
GitHub (github.com)
-
@steve I've built the server part already, that was 5 years ago. Still waiting for people with the skills to build the UIs though...
@mariusor
I was thinking about trying to build a lightweight wrapper around c2s that mimics the Mastodon/pixelfed API, and then just bootstrap every existing mastodon/pixelfed client but that feels like more work than it'd be worth -
@mariusor
I was thinking about trying to build a lightweight wrapper around c2s that mimics the Mastodon/pixelfed API, and then just bootstrap every existing mastodon/pixelfed client but that feels like more work than it'd be worth@tom I doubt you can reproduce the timelines and the tag following with anything lightweight.
It probably needs a lot of caching and reprocessing of collections... -
@tom I doubt you can reproduce the timelines and the tag following with anything lightweight.
It probably needs a lot of caching and reprocessing of collections...@mariusor Yeah that's where I was hung up with my mental model of it and why I haven't actually tried anything yet
-
@raphael @silverpill @steve 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 - 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 (github.com)
@evan @raphael @steve 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.
-
@evan @mariusor @steve oh neat!
Add Arrive outbox handler for check-in activities by pfefferle · Pull Request #2977 · Automattic/wordpress-activitypub
ActivityPub for WordPress. Contribute to Automattic/wordpress-activitypub development by creating an account on GitHub.
GitHub (github.com)
@pfefferle @mariusor @steve WHAT
-
@pfefferle @mariusor @steve that's awesome!
-
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.
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.
-
@steve I've built the server part already, that was 5 years ago. Still waiting for people with the skills to build the UIs though...
-
@evan @raphael @steve 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.
@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...
-
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.
@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).
-
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.
@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.
-
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.
@steve 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.
