The previous HTML method is gone due to a page restructure. It was
able to consistently bypass Instagram's blocking.
The IWeb method has a few hundred uses per X time for selfhosters, and
a couple dozen uses per X time for servers. This will likely change in
the future. There is no known way to bypass Instagram's IWeb blocking.
Feel free to look for a way.
Further timeline pages are still blocked. The "next page" button
defaults to not automatically loading when scrolled, since it will
basically never work anyway. Users running personal instances may be
able to get a couple of uses out of it.
It does not work.
It was created for an older era when the user page was most heavily
restricted, and graphql timeline was free. So the visitor would look
up the username-userID relationship on the instance's behalf, and
submit that for the instance to check, and then that profile would be
unblocked forever because the user page is not needed after that
point.
Now, the user page is free, and graphql timeline can be impossible.
(Still haven't worked that out yet.) So the unblocker would only be
fetching information that the instance could already get. Even if the
instance was somehow blocked from the user page, the unblocker would
not help, since it only fetches the username-userID relationship for
use with graphql timeline, and graphql timeline is currently blocked
on the instance too.
Keeping this in Bibliogram is misleading to visitors and the backing
code is now useless.
The correct way to view profiles is to run your own Bibliogram.
When pasting text in the user or post fields,
some unwanted whitespace may occur, especially from mobile device.
Currently, if this whitespace is before the username or the post,
Bibliogram returns 404.
This patch prevents this by trimming the unwanted whitespace.
- Use quota for /p/ requests
- Correctly detect owner.full_name to save unneeded requests out
- Unify quota reached pages
- Unify post presentation into function that fetches prerequisites
- Add getByID method to userRequestCache
