Should Fediverse Web apps show remote content to unauthenticated users?
For example, you point your browser at a.example. You are not logged in.
You navigate to a list of a local user's followers at a.example/user1/followers .
If you click on a profile in that list, it loads a.example/remote/user2@b.example , a profile page for a remote user.
If you click on an image posted by that remote user, it loads a.example/remote/b.example/image/33 , showing the remote image and all comments on it.
If this is not an interesting question to you, feel free to skip it!
Edited 6d ago
@evan
Yes, but...
- only when the original posts are public or quiet-public.
- with appropriate protections against "ai" scrapers and whatever other prevailing threats of the day.
@evan Yes, but don't do it in the UK otherwise it throws you right into compliance issues with the OSA.
With login only you can at least plausibly say all your users are over 18.
@evan oh this is a good one
I put "No", I think I prefer a redirect to the source. Though I think I could be pretty easily convinced that as long as the post marked "public" it should be fine
@evan … but it should be a user-configurable option to withhold even one's "public" posts from unauthenticated users.
This mitigates access by blocked harassers, requiring them the delay of creating new accounts, presumably backed by new email accounts, to even see content from users who've blocked them. That added delay and inconvenience should accelerate most trolls getting bored of, for example, screenshotting and subtooting those who they'd previously harassed directly.
Edited 6d ago
YB...
Probably yes for "public" content.
An instance might also limit heavier content to logged-in users to avoid performance issues (e.g. protect against getting DDOSed by a bot, etc).
@evan no but...
It should show a digest. Publishing and archiving are distinct from social media but the open web is not.
Discord is not an open web platform. Archiving is exfiltration. But an archive of a digest is just good practice.
The Fediverse is walking and chewing gum at the same time - social media on the open web. But that doesn't mean anonymous users get the privileges of social participation. They get some amount of aggregation and summarisation but as it comes with no expectation of reciprocity it comes with no guarantee of parity.
@evan I voted No, because if you're a curious onlooker checking out the Fediverse, and you start browsing all from within one website, you may mistakenly believe the website you're on *is* the Fediverse (or Mastodon since that's often the branding).
Debatable still. 🤷
@evan I voted "Yes, but" before I read your explanation post.
I was thinking of features such as server A showing a "From around the Fediverse" list of posts, perhaps "curated" with high numbers of likes or retoots (to avoid objectional content accidentally being shown).
I'm not a fan of server A becoming a de facto proxy to the rest of Fedi. A web crawl could destroy a small server by using it like a CDN. Not sure what is a good approach (my lack of knowledge, not that there isn't one).
@evan Yes but only because I can't think of a reason NOT to
@evan No... but maybe? I don't have a strong reason why they would. I feel like servers should only show their local content, for which they can control access based on publishing user's preferences.
There's also the question of caching: should you show cached remote content that has been deleted?
Except perhaps aggregators, and generally servers with nefarious intents that you can't control anyway (though you can block pushing content to them in the first place).
EDIT: ok, maybe in context of a conversation involving a local user.
Edited 6d ago
@evan No (not by default to not implicate unsuspecting self-hosters with legal issues of the third-party content served through their site), but if the admin wants to offer such a service to the public internet they should have easy options to enable it.
Edited 6d ago
@evan I would say no, if I'm understanding correctly. The browser should load b.example's content from b.example, not a copy from a.example . I'm mostly concerned about privacy here.
If a post or profile is *clearly* meant to be fully public to the world (and ideally it's hard for an author to do this by mistake), then I guess it's meant to be shared around, so sure, why not serve copies. Depending on the use case, there could be advantages to that.
@evan No...but..
By default no.
Would prefer if this is user choice.
(in the Time of Scrapers, it gets even more complex than that tho)
@evan besides what appears to be smart arse comments (apologies if wrong.) I say no, due to privacy.
If something is completely public then it's okay the user has chosen to make it public but if anything is not public it should require at the very least an account to view if it is semi-public (only users of the platform can view)
Ideally it would be something the user controls.
@evan Hm, thinking more on this, if an AP post is quoting a remote post I think I would expect to see the remote content on the original page so maybe I'm shifting back up to yes on my own
@evan I’d say very much yes. It shows the connectivity of fedi rather than implying fragmentation.
@evan I voted yes. As long as everything in the flow honors user2@b.example's visibility settings I think that should be fine (unless I'm missing something important in the premise).
Edited 6d ago
@evan To be clear, is 'it' in the above always the local browser as opposed to the server a.example (proxy-requesting on the unauthenticated user's behalf).
@evan Yes, depending on privacy settings of course. For public posts, absolutely yes
Thanks to everyone who replied! I am a "yes, but...".
Yes, but you should clearly identify it as remote content or a remote profile.
People on here freak out sometimes when they see remote profiles or remote content on a Fediverse-enabled server. They say it has "shadow profiles" or "scraped content."
Clearly identifying that it comes from the Fediverse can help with this a lot.
@evan just thinking, if user click on a remote profile, it could technically just go straight to remote server’s profile page? 🤔
Probably confusing for some users, but could potentially “educate” them that the fediverse actually consists of multiple servers linking/talking to one another.
Edited 5d ago
@evan I know you may have seen my message and couldn’t reply, and I understand. Please allow me to ask one gentle question. My mother and I live in a tent in Gaza. She is ninety years old, blind, and immobile. She suffered a stroke and urgently needs open-heart surgery. Her fragile body is covered in painful sores because we have no diapers. I watch her suffer every day, unable to ease her pain. It breaks my heart. Are the cases you choose to support more difficult than my mother’s? 💔
@evan Dear Evangelo,
Thank you from my heart for your generous donation. My mother was very happy when I told her about your kindness. Tomorrow I will buy her diapers because of you.
She is fasting these days, and she will pray for you every day during Ramadan, mentioning your name in her prayers.
May God bless and protect you always. 🤍
@virtuous_sloth the browser is loading a page on a.example that calls the API at b.example (either server-side or client-side, but much easier server-side) and formats the JSON response as HTML.
@evan That is not as clear as you seem to think.
When you say "the browser is loading a page on a.example" I think you really mean "the browser is loading a page *from* a.example". When you say "that calls the API at b.example" what I think you really mean is "the browser that has loaded the page from a.example which includes javascript code then runs that code which, in the browser, makes an HTTP connection to the b.example website, using the web API there to get some data. That data is ...
@evan either HTML representation of the information requested (in the case of server-side, which means server-side production of HTML which is then rendered in the browser, possibly as a subsection of the loaded page from a.example) or is simply data which is then received by the javascript in the browser that is then rendered into HTML by the javascript (in the case of client side), perhaps directly modifying the DOM of the page in the browser.
Maybe. I think developers think they are being...
@evan clear when they are really relying on the reader to have developer-level understanding of all the moving parts that are hinted at by plain English words that do not mean the loaded information without explicit knowledge by the reader.
I'm not a developer, have a very good understanding of where code can run in what contexts on multiple servers with data flowing between them, which is how I guess at the above, but do not know enough details to be sure.
@evan And yes, I know that any communication would be tortuous if you had to assume nothing of your reader.
I suppose that is why I do appreciate it when you qualify your surveys with, for example, "Full-stack developers only".
@evan To be more explicit, I think I understood your explanatory reply to your original survey but wanted clarification that the repeated word "it" was referring to the user's browser, or perhaps "the user's browser running javascript loaded in the page fromm a.example".
Your first sentence response to my question seemed to confirm this. But then your followup about server-side or client-side made me wonder if my contra-example of a.example proxying interaction with b.example was correct.
@virtuous_sloth It's usually correct. A lot of Fediverse servers use CORS or authenticated fetch to prevent loading the data directly into the browser. I feel like you're getting very particular about how it's implemented, which is fine. If that's important to you, express why and how it affects your answer in a reply.
@evan Very well.
I'm trying to understand even the point of the question. In my mind, a web app running in a user's browser is under the user's control, for the most part, so even if the author of the web app thinks the answer is 'no' they have little recourse for users who modify the web app to show remote content when unauthenticated.
Should an unauthenticated user have access to data on b.example is a decision for b.example. But if b.example trusts a.example and a.example proxies...
Edited 6d ago
@chillicampari @evan
That was my concern exactly (I voted "yes, but"):
e.g followers-only content shouldn't be public just because a follower's instance has access to it. In a perfect world this would have been end to end encrypted.