Conversation

Notices

1. Embed this notice
   anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 04:23:02 JST anna
   ok how does this idea sound:
   
   to have kinda like auth_fetch but for clients. when you log in a client you generate a key that goes to your home server. when you make a client<>server ap request, you include that key, and the receiving server can validate that against your home server, using an activitypub extension.
   
   this would still allow servers to block servers, and it would avoid allowing malicious servers querying data using the client api, as well as being compliant with base ap
   
   the only negative is that if your server *hard* requires this auth for every ap query, you won't have anonymous access, but then it's a trade off between hard blocking servers and allowing un-logged in users
   
   hmmmm
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 04:22:58 JST :blobcathug:

     in reply to
     @navi
     > this would still allow servers to block servers, and it would avoid allowing malicious servers querying data using the client api, as well as being compliant with base ap
     :blobcatgoogly: you know that you can restrict the unauthorized client api?
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 04:44:27 JST :blobcathug:

     in reply to
     @navi they tried to make a unified server <> client protocol once... But thats not a good idea since every server/client has different flavors/advantages so a unified API would prevent customizations...
     
     > the client api is used to render the same info available from the ap api
     Thats oversimplified... Yes, in the end, a post is the same. But let me make an example: if you wana look at a post/object, the whole conversation will be loaded at once. If you would make the server more stupid, the client would have to query anything manually.
     
     > just that many servers have auth_fetch on the ap one, and no auth on the client one
     Thats very different from my experience tho. Take for example the configuration of blob.cat. We allow an unauthentic user to query the public timeline. We also allow to query the conversation of a whole thread, but in a very limited way. Many other instances prevents to load anything if you are not authenticated...
     
     > with just makes the auth in the ap one kinda useless for stopping malicious actors
     i agree on that and im in the opinion that it doesnt make sense to turn on auth_fetch at all... I do have that controversal opinion because it only makes sense in a environment where you have a whitelist instead of a blacklist.
     Beside of that, if you look at it from a IT Security Perspective, you have to assume that even if you lock down the ap api, lock down the client api, use a whitelist, that still posts of your instance could be found on unlocked client apis on a server which you federate with.
     The whole purpose of the fediverse is to share informations public and there is pretty much no way around that
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 04:44:32 JST anna

     in reply to

     • :blobcathug:
     @Jain yeah, but at this point the client api is just a duplicate of the ap api (which is made for client<>server too, not only server<>server)
     
     the client api is used to render the same info available from the ap api, just that many servers have auth_fetch on the ap one, and no auth on the client one, with just makes the auth in the ap one kinda useless for stopping malicious actors
     
     and if you put auth on both... why have two apis?
     :blobcathug: likes this.
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 05:28:12 JST :blobcathug:

     in reply to
     @navi
     > nop, that's what one can use ap extensions for (json-ld is good in making different stuff interoprate, if that is what is wanted, that's why it's used), or if you really must, make api points for your unique stuff, but let ap handle the objects of the core protocol
     
     :blobcatthink: i think there is a big difference when a extension is used as a small extension of a object or that a complete conversation would be available inside an extension... beside of that, i think the servers do have mainly the role of passing ap objects but without their flavors fedi wouldnt make fun...
     
     > https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto
     > https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies
     > those two already cover loading an entire conversation on a single get request (get the post you wanna render, and you get what it is a reply to, and stuff that replies to it)
     
     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/
     
     > this could be mitigated if the way client operate were to go to the origin to get the full definition of objects, not one's cached/federated home server.
     
     but this implies that you only store the local objects on the server and always fetch every remote objects for security reasons...
     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 :blobcatgooglynotlikethis:
     
     > tho about this, i like and dislike this approach, and i'll elaborate on that later when i am a bit deeper into developing libactivity
     :blobcatthinkOwO:
     
     ok, i will generalize things a bit now... i get the feeling of you that fedi should be build upon a server / client protocoll that is way more privacy aware... something like matrix would even fit better maybe? In general: 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...
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 05:28:17 JST anna

     in reply to

     • :blobcathug:
     @Jain
     
     > But thats not a good idea since every server/client has different flavors/advantages so a unified API would prevent customizations...
     
     nop, that's what one can use ap extensions for (json-ld is good in making different stuff interoprate, if that is what is wanted, that's why it's used), or if you really must, make api points for your unique stuff, but let ap handle the objects of the core protocol
     
     > But let me make an example: if you wana look at a post/object, the whole conversation will be loaded at once. If you would make the server more stupid, the client would have to query anything manually.
     
     https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto
     https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies
     
     those two already cover loading an entire conversation on a single get request (get the post you wanna render, and you get what it is a reply to, and stuff that replies to it)
     
     > Take for example the configuration of blob.cat. We allow an unauthentic user to query the public timeline. We also allow to query the conversation of a whole thread, but in a very limited way. Many other instances prevents to load anything if you are not authenticated...
     
     this all can be done via just... returning different stuff from the ap api, depending on auth, and https://w3c-ccg.github.io/zcap-spec/ might make this easy with capabilities (i need to read the spec in full, but it looks like it does)
     
     > Beside of that, if you look at it from a IT Security Perspective, you have to assume that even if you lock down the ap api, lock down the client api, use a whitelist, that still posts of your instance could be found on unlocked client apis on a server which you federate with.
     
     this could be mitigated if the way client operate were to go to the origin to get the full definition of objects, not one's cached/federated home server. tho about this, i like and dislike this approach, and i'll elaborate on that later when i am a bit deeper into developing libactivity
     :blobcathug: likes this.
   • Embed this notice
     Ada (ada@mk.wytch.space)'s status on Wednesday, 26-Jul-2023 05:47:58 JST Ada

     in reply to

     @navi@social.vlhl.dev Authorized Fetch is very primitive and direct, but it doesn't really work for peered connections (which is what this would be.) The key exchange only works halfway, and doesn't seem to be thought through.
     
     This is probably why PeerTube has issues implementing it, because it would de-decentralize the platform.

     :blobcathug: likes this.
   • Embed this notice
     Ada (ada@mk.wytch.space)'s status on Wednesday, 26-Jul-2023 05:47:59 JST Ada

     in reply to

     @navi@social.vlhl.dev i think this is what people mean with "Don't roll your own crypto"
     
     or in this case "don't roll your own key exchange"

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 05:48:01 JST anna

     in reply to

     • Ada
     @ada the cache would also help with reducing the amount of connections needed to parse any given request
   • Embed this notice
     Ada (ada@mk.wytch.space)'s status on Wednesday, 26-Jul-2023 05:48:02 JST Ada

     in reply to

     @navi@social.vlhl.dev essentially have the homeserver co-sign the key which can be validated later with the homeserver's public key either on request or cached (all of which has an expiry date of like 30 days)

   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 05:52:57 JST :blobcathug:

     in reply to
     @navi
     > 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?
     Ok, i do have a bad feeling but i agree, a proper redesign of client apis would make certain things easier
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 05:53:03 JST anna

     in reply to

     • :blobcathug:
     @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
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 05:53:21 JST :blobcathug:

     in reply to

     • :blobcathug:
     @navi will answer the rest later
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Wednesday, 26-Jul-2023 06:40:41 JST :blobcathug:

     in reply to
     @navi There isnt much to answer tho
     
     btw, currently of the biggest 3 servers, only misskey doesnt support the mastodon API, i read that firefish have it too
     
     For the last part, im not sure if we understand us completly, but im looking forward to your projects then...
     
     Unify a client json-ld API sounds good, but "hardening" the protocol to protect public posts seems to me still useless since i didnt look at zcap yet and I don't think one could prevent the problems, and one could, it would hurt the network
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 26-Jul-2023 16:26:01 JST anna

     in reply to

     • :blobcathug:
     @Jain the zcap part would replace what autorized_fetch already does, but in a way that is a lot more flexible in regards to permissions, so we don't just plainly block everything that is not a server trying to access ap apis
     
     > btw, currently of the biggest 3 servers, only misskey doesnt support the mastodon API, i read that firefish have it too
     
     i honestly really dislike the "mastodon does everyone follows" flow of things, but such is life and i know we're not getting away from that soon, tho i will try to
     :blobcathug: likes this.