search

tuskyapp / Tusky

An Android client for the microblogging server Mastodon
https://tusky.app
GNU General Public License v3.0
2.5k stars 390 forks source link

Can the app pull more info from specific servers? #2539

Closed kefir- closed 1 year ago

kefir- commented 2 years ago

When I open a user's profile there's a standard text showing that more info on posts, follows and followers is available by opening the account in a web browser. Screenshot below.

Is it not possible to view this information directly in Tusky? The information is readily available on the web, is there no API that could be used by Tusky to display the same complete server specific info in-app?

I'm not so concerned with the counts being a bit imprecise, but using Tusky to discover users and networks by looking at who is following who gets tedious when I keep having to fall back to the browser.

Screenshot: Screenshot_20220518-012110_Tusky

charlag commented 2 years ago

It's just a general note that the information can be imprecise with federation. I think we added it because Mastodon also had it but maybe we should change it. Web UI shows this under the followers/following list

Screenshot from 2022-05-18 08-10-15

I don't think we should try to pull info from random places, we need to trust our server which checks various things for us.

kefir- commented 2 years ago

I certainly didn't mean to pull info from random places, but maybe that is how this would work, because the app would be communicating with some random mastodon server? I'm still working on my understanding here. I guess there's a threat model to consider.

But the idea was that the link directs the user on to the original profile, and my question was whether info can be pulled from there into the app instead of pushing the user over to the browser. The app often shows so little info that one could argue that it might as well not bother, and rather link directly to the original profile.

niklasdewally commented 1 year ago

I find this related to this issue for the mastodon server https://github.com/mastodon/mastodon/issues/34 .

I agree with the premise that the server should be responsible for filling in the profile data, not Tusky.

However, the above discussion around how to fix having to open the browser to view old toots for a user has existed for a long time, and there doesn't still seem to be an agreement on how to add this server-side.

Fixing this issue in this app instead could be an easy stopgap until the mastodon maintainers see this as a priority, or I get round to learning Ruby and submitting a PR.

If the user must click a button to load more content within the app, I don't see why the threat model would be any different than clicking a link to go to a website.

I think that having the user opt into fetching the remote content (either via settings, and/or a "load more content" button) wouldn't be detrimental from a privacy perspective, but would make huge UX improvements.

I have a few thoughts about how these threat concerns would apply to statuses.

I would be happy to turn this into a PR once a consensus is reached on how this should be implemented.

niklasdewally commented 1 year ago

There is a similar conversation happening for the official app currently at: https://github.com/mastodon/mastodon/issues/21571

robsonsobral commented 1 year ago

@niklasdewally , take a look, please.

niklasdewally commented 1 year ago

@niklasdewally , take a look, please.

Thank you for this- I 100% agree with what you said here!

I wasn't clear enough about what I called "opt-in" - your post fleshes this out wonderfully!

I think your proposal for implementation is the way to go :)

niklasdewally commented 1 year ago

(Cc: @charlag I know you were opposed to this before as the client would be pulling in random data from random places - is this still a concern when using an opt in system as described above?)

robsonsobral commented 1 year ago

I wasn't clear enough about what I called "opt-in" - your post fleshes this out wonderfully!

I gonna try to mock some images next days to make it easier to present the idea to Big G.

charlag commented 1 year ago

(Cc: @charlag I know you were opposed to this before as the client would be pulling in random data from random places - is this still a concern when using an opt in system as described above?)

my concerns are:

I don't like features which need a lot of explanation. I also don't like plugging in holes in server impl on the client, we already do it too much.

Ciantic commented 1 year ago

I kind of get the concern, but if user is viewing @ConnyDuck@chaos.social's account, then user is already giving some trust for chaos.social. Why can't the user then choose to pull that info from chaos.social, just like they can by going to there with browser?

Move the responsibility to user if it's too 'risky'.

You could say that "Following data is coming from chaos.social" and just show it. How is redirecting to browser increasing privacy? Isn't user just as gullible in browser as they are in the UI.

connyduck commented 1 year ago

I agree with charlags points, we shouldn't do it. Apart from that I wouldn't even know how to do it. We would have to implement ActivityPub for that, right? Because we can't assume the server speaks Mastodon Api. But can you even pull info via ActivityPub as a client?

Ciantic commented 1 year ago

@connyduck

Some clients already do this for instance:

# Get Gargron@mastodon.social
curl -X GET "https://mastodon.social/.well-known/webfinger?resource=acct:Gargron@mastodon.social"
# From above you should find aliases, each of them work, e.g. https://mastodon.social/users/Gargron

# Then query ActivityPub profile from that alias:
curl -X GET -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://mastodon.social/users/Gargron

# Then query more interesting stuff from profile, like followers:
curl -X GET -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://mastodon.social/users/Gargron/followers

# This may fail if user has hidden ones followers:
curl -X GET -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://mastodon.social/users/Gargron/followers?page=1

# Get first page of public posts
curl -X GET -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' "https://mastodon.social/users/Gargron/outbox?page=1"

ActivityPub spec, 3.2 Retrieving objects contains the header used for retrieving objects as 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"'

charlag commented 1 year ago

I don't think anyone even considered that the other app might not speak mastodon client api until now but that's a good point.

Answering ciantic about trust, there's a difference between viewing some remote webpage and viewing stuff in the app. We would have to but a banner on top which says "this info might be fake don't trust it" or something like that.

Answering ciantic about the requests, this is basically trying to do half-assed AP requests, without HTTP signatures or user agent. I can't in good conscience recommend doing AP requests like that.

Ciantic commented 1 year ago

@charlag of course that was demonstration, because conny asked how to do it. I don't think any client uses CURL for real to that...

I'm just saying, some clients are doing that already.

charlag commented 1 year ago

Ok, it's my fault, I shouldn't have taken it like a finished sample but still, is it even possible to implement HTTP signatures without having a resolvable actor?

Also the very fact that we have to think about this tells us that something is very wrong about the project scope and this issue.

Ciantic commented 1 year ago

I don't know a lot more. The user's PublicKey which I think is being used to verify signatures is in that ActivityPub profile (one of the CURL examples above gives that PublicKey).

I do very well understand why official Web client, and servers in general don't do this, it kind of jumps outside the federation idea, and goes to realm of trust. Which I guess is pretty contentious among decentralization absolutist.

This however is being implemented in other apps with ActivityPub APIs just like in the curl example for better UX.

But can you even pull info via ActivityPub as a client?

Any client can connect. This is in fact many times required, it would be impossible to do a whitelist of ActivityPub servers. Any WordPress blog for instance can be ActivityPub "server".

ActivityPub is pretty simple and public API, it doesn't have trust among parties that don't know each other. It's basically always publicly available and someone can go and troll to inboxes anything they wish. That's why manual follow requests is advised.

kefir- commented 1 year ago

Could Tusky have a button to try to fetch account info like followers and following using mastodon's api? If that fails (eg it wasn't a mastodon server) Tusky might have functionality for other apis as well, and fall back to manually browsing the website as a last resort?

Mastodon's API seems fairly straight forward, but I'm not sure how it works against a different instance where the user isn't logged on.

https://docs.joinmastodon.org/methods/accounts/#followers https://[site]/api/v1/accounts/[user_id]/followers

Ciantic commented 1 year ago

@kefir- we just had discussion above, it's not possible with own server's Mastodon API. This is intentional, because the other server can lie, but your server's Mastodon API has internal representation of the whole network it knows, and it's build own follower count that way. This is why follower count of a person viewed from own server differs from remote servers follower count.

You could always try to pull it from ActivityPub or other servers API. ActivityPub API is most compatible, as it would work for other ActivityPub servers as well like Peertube, Micro.Blogs, WordPress etc.

kefir- commented 1 year ago

Yes, my suggestion was to use the api on the viewed account's own mastodon instance, though I see that I could have worded that better. And not necessarily automatically when viewing an account, but when the user requests it.

I see that this will only work for mastodon servers. If the api fails, tusky can always fall back to the web browser like it currently does.

I don't quite understand the concern with lying servers. If they can lie in the api, they can surely lie in the web browser as well?

Ciantic commented 1 year ago

@kefir- you don't need to use Mastodon API.

There is ActivityPub API that provides all the same info, and it's public, and works for any account.

I just gave CURL commands to explore that ActivityPub API, devs can figure it out from there.

charlag commented 1 year ago

I will close this because this is out of scope and it won't work (besides signing problems above there's a problem that you won't see follower-only stuff which is yet another confusing point). All core devs agree with this. We need better servers, not client hacks.

blauertee commented 1 year ago

I'm not sure whether I agree. With commercial platforms the most important task of alternative clients always has been client-hacking the server. And sure it would be wonderful if the mastodon team would think of a solution for this, but if they don't (and it seems like they don't). I don't see how this is different.

It's just something really anoying for users that could easily fixed with the only contra point being "it's not a pretty design choice"

I don't think the security points apply at all.