Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

site field of ResolveObjectResponse #4636

Open
5 tasks done
Sjmarf opened this issue Apr 16, 2024 · 2 comments
Open
5 tasks done

site field of ResolveObjectResponse #4636

Sjmarf opened this issue Apr 16, 2024 · 2 comments
Labels
area: api enhancement New feature or request

Comments

@Sjmarf
Copy link

Sjmarf commented Apr 16, 2024

Requirements

  • Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
  • Did you check to see if this issue already exists?
  • Is this only a feature request? Do not put multiple feature requests in one issue.
  • Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
  • Do you agree to follow the rules in our Code of Conduct?

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 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:

  1. Contact the instance that you want to block directly.
  2. Use GetPosts on that instance to get a single local post.
  3. 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.
  4. Take the id of the returned CommunityView and query GetCommunity to get the Site.
  5. Finally, use the id of the Site to make a BlockCommunity request.

Additional context

No response

@Sjmarf Sjmarf added the enhancement New feature or request label Apr 16, 2024
@dessalines
Copy link
Member

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.

@Sjmarf
Copy link
Author

Sjmarf commented Apr 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants