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
I'm reading through the code and documentation, and most of the dynamic nature seems to be around the authentication - not the actual serving of user data (besides the internal retrievals and real-time parsing, that is all negated when statically hosted as we process ahead of time).
I am proposing a READ ONLY structure to the PDS API. One that we could flush out with 100s of directories and index.html files in an S3 bucket or Github pages, that the network can just pull data from.
It's public data. There's no reason we should limiting access to it behind all of these PDS authentication protocols, as well as requiring unnecessary server-side processing in real-time.
Want an ECO angle? This is extremely wasteful for the planet, to process the same Public data over and over again, on each request. Processing authentication protocols for, again, public data. Static hosting has proven to reduce massive CPU processing in data centers (massive power usage drop, less switching processing of traffic) simply by parsing once ahead of time, and storing the Public json/html/js result to serve statically at a CDN. As the world explodes with PDS, this may be the time to cut the carbon footprint.
The goal? The ability for an end-user to setup a PDS to serve static content on the network. Like my BlueSky posts, and posting to my static blog.
I believe we should not have to setup a dedicated VM, just to serve static public content on these networks. A dynamic AppView? Absolutely for security and moderation. However, not the PDS static public data.
If I am missing a security angle, please elaborate and we can close the issue.
The text was updated successfully, but these errors were encountered:
It is good signal/feedback that you asked for this, and wrote out a bunch of helpful details, don't want to lose that. Maybe best if you copy your text, with a note, to one of the existing threads, and then close this issue?
I'm reading through the code and documentation, and most of the dynamic nature seems to be around the authentication - not the actual serving of user data (besides the internal retrievals and real-time parsing, that is all negated when statically hosted as we process ahead of time).
I am proposing a READ ONLY structure to the PDS API. One that we could flush out with 100s of directories and index.html files in an S3 bucket or Github pages, that the network can just pull data from.
It's public data. There's no reason we should limiting access to it behind all of these PDS authentication protocols, as well as requiring unnecessary server-side processing in real-time.
Want an ECO angle? This is extremely wasteful for the planet, to process the same Public data over and over again, on each request. Processing authentication protocols for, again, public data. Static hosting has proven to reduce massive CPU processing in data centers (massive power usage drop, less switching processing of traffic) simply by parsing once ahead of time, and storing the Public json/html/js result to serve statically at a CDN. As the world explodes with PDS, this may be the time to cut the carbon footprint.
The goal? The ability for an end-user to setup a PDS to serve static content on the network. Like my BlueSky posts, and posting to my static blog.
I believe we should not have to setup a dedicated VM, just to serve static public content on these networks. A dynamic AppView? Absolutely for security and moderation. However, not the PDS static public data.
If I am missing a security angle, please elaborate and we can close the issue.
The text was updated successfully, but these errors were encountered: