What if...
-
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@social.technoetic.com I wonder if we want 1 single fediverse account for everything or if it still makes sense to split our identities for different needs
1 server centralizing all my fediverse accounts (via C2S for standardisation) and 1 or multiple client apps to read from this server would be another option. Any thoughts? -
@steve@social.technoetic.com looks similar to https://activitypods.org/ approach ?
@nathan Yes, ActivityPods (Mastopod) is similar, but based on Solid and RDF. The last time I checked, their C2S client was specific to Mastopod. However, that may have changed.
-
@steve@social.technoetic.com I wonder if we want 1 single fediverse account for everything or if it still makes sense to split our identities for different needs
1 server centralizing all my fediverse accounts (via C2S for standardisation) and 1 or multiple client apps to read from this server would be another option. Any thoughts?@nathan Nothing I'm describing would force you to have one account. With multiple accounts, if they are hosted in one server or across multiple servers doesn't change the approach. For now, I'm discussing single actor clients, but theoretically multi-actor clients could be written too (I haven't thought much about that).
-
@nathan Nothing I'm describing would force you to have one account. With multiple accounts, if they are hosted in one server or across multiple servers doesn't change the approach. For now, I'm discussing single actor clients, but theoretically multi-actor clients could be written too (I haven't thought much about that).
@steve@social.technoetic.com yes indeed it would still be possible to have multiple identities with your proposal
I'm also thinking about the migration path. As many people already have accounts on mastodon or others, should they migrate to this new one ? -
@steve@social.technoetic.com yes indeed it would still be possible to have multiple identities with your proposal
I'm also thinking about the migration path. As many people already have accounts on mastodon or others, should they migrate to this new one ?@nathan It's too early to say, but the improved UX enabled by an extended AP C2S would potentially motivate users to switch. The migration support will depend on the server implementations (Mastodon-style, LOLA, Nomad, ...).
-
@nathan It's too early to say, but the improved UX enabled by an extended AP C2S would potentially motivate users to switch. The migration support will depend on the server implementations (Mastodon-style, LOLA, Nomad, ...).
@steve@social.technoetic.com correct I'm a bit too much anticipating
let's build step by step ! -
@mariusor @steve Does your server work with https://checkin.swf.pub/ ? Or https://github.com/evanp/ap ?
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=https://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: https://datatracker.ietf.org/doc/html/rfc7591#section-2
-
-
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=https://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: https://datatracker.ietf.org/doc/html/rfc7591#section-2
@mariusor I'll check it!
-
@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.
