Re: "Specifying Spring ‘83"
Message headers
From: Matthew Ernisse <matt@going-flying.com>
Subject: Re: "Specifying Spring ‘83"
Date: Tue, 14 Jun 2022 14:06:19 -0000 (UTC)
Message-ID: <slrntah5er.23p.matt@imladris.colo.ub3rgeek.net>
Message content
On Tue, 14 Jun 2022 07:01:33 +0200, Gustaf Erikson wrote:
Matthew Ernisse <matt@going-flying.com> writes:
>
> Do we think that someone is going to actually write a whole native client
> including a rendering engine to do all the modern HTML and CSS bits as
> opposed to just doing JavaScript (either as a webpage or as an Electron
> app)? If we do end up using JavaScript then how do we expect people not
> to put tracking stuff in at the app layer? It's just so easy to do
> unintentionally (as well as intentionally) given that nearly no-one writes
> their own JavaScript anymore. If we have JavaScript at the app layer
> why not allow the boards to access it? Looking at all the 'companion
> specs' that flew around to add stuff that Gemini specifically left out
> it's pretty obvious that people would do the same to this.
>
I would expect the first client implementations to be a web service,
yes. As to why the client can't implement tracking... it can? Is that
really something this project is trying to solve? I'd imagine each
item can also use tracking pixels, like email.
I guess my point was the spec takes some care to try to specifically
eschew this kind of analytics and data collection behavior but the most
obvious implementations can quite easily -- by accident even, sidestep
that intent.
It would be trivial for a developer to require a npm package that
requires a npm package that quietly pulls in an analytics package.
If you're an author of a item it's up to you to preserve your content's
history with local backups. The current situation, where we kind of
assume YouTube is gonna keep all our stuff up online forever is probably
not sustainable.
Pretending YouTube is going to be around forever is madness, but randomly
deleting published works based on an algorithm seems like it takes the
control out of ther author's hands and puts it into some omnipotent server
operator's hand -- which begs the question of why someone would want to
publish their work on this.
> I feel like this idea is trying to be a modern netnews where servers flood
> injested boards (articles) to peers and allow the whole network to have
> a copy, or to use a more modern example a persistent distributed message
> bus. In both cases though it should be up to the server operator how much
> storage and resource to dedicate to the task.
>
The item size and amount limit are to ensure that anyone with a $5/mo
VPS can be a server operator and part of the ecosystem. Thus, it moves
the focus of Gemini from ease of client development to ease of server
hosting.
Maybe that's why I don't get it. The focus is on the server operator
not the authors. It seems silly to impose limits on the people making
the stuff that makes the server relevant just to make the server a little
cheaper to host.
I'd also point out that who cares about a VPS? This is simple enough you
could implement it with Azure Functions for essentially free, then store
boards in Azure Blob for $0.02/GB/month and your 22GB ends up being... about
$0.45/month... and that's today's pricing.
I think it would be better to encourage as many authors as possible so
there is something to look at.
--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh
Related
Parent:
Start of thread: