You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a client developer, it is difficult to allow users to block instances by domain name. This is because the BlockInstance request accepts an instance_id, which can only be accessed from a Site, which can only be accessed from GetCommunityResponse or GetPersonDetailsResponse. There is no easy way of getting a Site object from a domain name, so it's tricky to find the ID with which to make the BlockInstance request.
Describe the solution you'd like.
A site field could be added to ResolveObjectResponse, allowing a domain name to be converted into a SiteView.
Alternatively, a domain_name field could be added to BlockInstance (and potentially also BlockPerson and BlockCommunity).
Describe alternatives you've considered.
This process could be used to get the site ID, but it's unideal:
Contact the instance that you want to block directly.
Use GetPosts on that instance to get a single local post.
Take the actor_id of the community that the post was made to, and use ResolveObject back on the logged-in instance to get the corresponding CommunityView.
Take the id of the returned CommunityView and query GetCommunity to get the Site.
Finally, use the id of the Site to make a BlockCommunity request.
Additional context
No response
The text was updated successfully, but these errors were encountered:
As a client developer, it is difficult to allow users to block instances by domain name. This is because the BlockInstance request accepts an instance_id, which can only be accessed from a Site, which can only be accessed from GetCommunityResponse or GetPersonDetailsResponse. There is no easy way of getting a Site object from a domain name, so it's tricky to find the ID with which to make the BlockInstance request.
Manually typing a domain name in a text field to block, doesn't seem like the best way to block content from a site you don't want to see. Blocking should occur based on things you see in the front end. The flow would be:
See a post or comment on your feed you don't like.
Have the option to block the entire instance.
This means adding Site to more view structs, probably also to the post and comment views.
I agree that blocking instances directly from the frontend would be the most convenient implementation, and that's indeed what we're adding to community and user pages. If it were to be made easily available for posts and comments API-wise, we would certainly consider adding a "block instance" action there too.
I don't think it's unreasonable to also have a "+" button in the list of blocked instances wherein a user could add an instance manually. If a user blocks an instance but then also wants to block the instance from another account, a manual input would be the most convenient option.
Requirements
Is your proposal related to a problem?
As a client developer, it is difficult to allow users to block instances by domain name. This is because the
BlockInstance
request accepts aninstance_id
, which can only be accessed from aSite
, which can only be accessed fromGetCommunityResponse
orGetPersonDetailsResponse
. There is no easy way of getting aSite
object from a domain name, so it's tricky to find the ID with which to make theBlockInstance
request.Describe the solution you'd like.
A
site
field could be added toResolveObjectResponse
, allowing a domain name to be converted into aSiteView
.Alternatively, a
domain_name
field could be added toBlockInstance
(and potentially alsoBlockPerson
andBlockCommunity
).Describe alternatives you've considered.
This process could be used to get the site ID, but it's unideal:
GetPosts
on that instance to get a single local post.actor_id
of the community that the post was made to, and useResolveObject
back on the logged-in instance to get the correspondingCommunityView
.id
of the returnedCommunityView
and queryGetCommunity
to get theSite
.id
of theSite
to make aBlockCommunity
request.Additional context
No response
The text was updated successfully, but these errors were encountered: