How to present the terms of use of the atproto service

[yamarten]

Third-party PDS users must comply with at least two types of terms of use. One is for the service, and the other is for PDS. The PDS terms of use can be shown in describeServer when registering an account, but Bluesky's appview does not implement this API.

Isn't there an API to know the terms of use of the service? Or is it expected that the client or PDS who determines the endpoint of the service will know the terms of use of the service in an informal way and present it to the user?

For example, if I use the PDS code provided by this git repository, do I need to link the terms of use of the service pointed to by PDS_BSKY_APP_VIEW_URL from the terms of use of my PDS?

[bnewbold]

That is a pretty interesting question!

The inclusion of PDS_BSKY_APP_VIEW_URL as a PDS configuration variable is a legacy/transition thing. In earlier days, we did not have a mechanism for clients to route requests through the PDS to specific service providers, so we hard-coded a set of endpoints to the Bluesky AppView. When we updated the PDS code to work better for self-hosters, we made this configurable so any compatible AppView could be specified. More recently we finished the client-driven proxying mechanism, but retained the default/previous behavior for app.bsky.* endpoints, so that other clients wouldn't break. In theory we should be able to fully deprecated the default-routing behavior, though we'd want to give clients more time to update to explicit routing (using the proxy header), and update our docs and examples first so it is clear how to transition. Maybe this will make sense as part of the OAuth transition coming soon?

Specific to your question, I don't think the PDS needs to announce the terms of any other services in the network. There is a direct service relationship between humans and a PDS host. We consider the relationship with the AppView to mostly be mediated by the client app (which is expected to set a default AppView provider).

It is technically possible to imagine flexible apps which allow swapping out AppView backends though, and such apps might want to display a ToS for the specific instance, so having some form of ToS link available from the AppView would make sense.

Thanks for the report!

[yamarten]

I understood. In the future, PDS will not implicitly choose appview, right? If so, you can assume that the client or user knows the terms, so there certainly seems to be no problem.

As you said, it will be better if atproto prepares a way to get the terms, so I'm looking forward to it.