@Jain

> i think the servers do have mainly the role of passing ap objects but without their flavors fedi wouldnt make fun...

servers will still have their flavours, but if those flavours could be extensions with a new json-ld context, instead of 15 new api endpoints, wouldn't it just be simpler for clients to support them?

> i guess my example doesnt fit the situation... but lets take the difference of pleroma/akkoma to mastodon as a better example for features then:
https://docs.akkoma.dev/stable/development/API/differences_in_mastoapi_responses/

honestly all i see here is additions to parameters, and queries to api endpoints, which both could be ap extensions, but maybe some couldn't? i'm not that deep into the apis they use, but like, notifications could be an ext for example

> but this implies that you only store the local objects on the server and always fetch every remote objects for security reasons...

stuff like the inbox and outbox would still send you the full list of things federated to you. just that now to get more info about a specific object, you go to the origin, which

> and when that happens then every server need to block unwanted clients... to do so the server has to create some kind of token on the remote server which then got passed to the client so that the client can load data from the remote server

the server already has to block unwanted servers and users, and even if we did change to that, that doesn't change. and with the auth mechanism that i am thinking of, (it probably is zcap-ld) that will be simple to check, no need for tokens on remote servers.

> i do like the ideas, but it sounds suddenly more like a very different approach with its own dynamics and im also not sure if thats a good thing... after all, thanks to how it works today, im able to find people to talk interesting stuff and i think that a more restrictive version of fedi would make it much much harder to connect people that dont know each other...

i don't want to change the core of it, just want to push to using the standardized apis and alike, so that writing tools and clients that work everywhere doesn't rely on implementing 3+ different apis on your code, if the core api is the same everywhere, and we do have an api that could be that, the ap api