with all these new federation compatible apps coming up im ever curious to see how people adopt accounts and UIs. will you be mixing content from all the different platforms together? will you create different accounts based on platform/topic? perhaps create some kind of meta ui that allows you to filter content in different ways for different purposes?
very interesting times for the fediverse.
@0x3F I hope to see all the existing apps properly implement the server>client part of the #ActivityPub spec. That way, instances can choose the back-end they prefer, and offer their users a choice of clients, so they can have the UI they prefer (and try new ones out) without having to constantly set up and keep track on new accounts.
@strypey but what about nextcloud instances that implement activity pub? should they also implement full servers?
this does seem like part of a good solution though. how would you allow users to switch? set up Pinafore/brutaldon style frontend-only pages for clients? how would you tell people about them? what about mobile clients?
just throwing out ideas.
@0x3F @strypey If possible, I would like more #ActivityPub compatible services on the same domain: at example.com I would register my username "alexl", then I go on cloud.example.com and login into Nextcloud instance with "alexl" username and password, the same for social.example.com with a Mastodon instance.
@alexl @0x3F LDAP? Check out what #Disroot.org are doing with that. Not sure how many AP services they have yet, but #NextCloud is on there, and they are beta testing #Hubzilla.
@strypey the problem is that we need AP's client-server protocol used between (Mastodon's) frontend and backend and extended for each application, like GitPub is doing for pull request.
Imo #activitypub should have the following extensions: microblogging posts (toots), comments to articles, pull requests, forks and issue tracking, reviews/votes about products and the other use cases to federate everything. Now it seems too much generic
@alexl What I know about federation protocols would fit on the back of my hand, but ... #GitPub is a pretty specific and uncommon use case, it's not suprising it needs a few extension to standard #ActivityPub vocab. But surely micro-posts don't need an AP extension, they are the core functionality of the whole standard! Also, why can't comments use the same data type as micro-posts?
@strypey when I talk about microblogging client-server API I'm referring to all those features that can be shared between platforms (Mastodon etc) like privacy or blocking features.
You would like to block users from a generic ActivityPub mobile app, no?
@alexl are blocking and muting not supported in vanilla AP? That seems odd, given they were in use via OStatus in both #Mastodon and #GNUSocial + #Qvitter, during the AP drafting process (and maybe even before it began), but OK. Or are you saying they are supported in the server > server API, but not the server > client API?
@strypey I'm just saying that applications like Mastodon should use AP client-server API for everything and eventually extend the protocol where it makes sense 🙂
@strypey username@pod.disroot.org for technical reasons