💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 87fsk796tu.fsf@news.geriks… captured on 2024-02-05 at 09:46:06. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
From: Gustaf Erikson <gerikson@gmial.com>
Subject: Re: "Specifying Spring ‘83"
Date: Tue, 14 Jun 2022 07:01:33 +0200
Message-ID: <87fsk796tu.fsf@news.gerikson.com>
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.
Looking at the server side got me more into the 'why would I use this'
mindset. I suppose the impetus is 'everyone has to have everything'
that naturally spawns a system to create backpressure to object creation
as well as aging. In the face of an omnicient Google I can sort of
understand the desire to allow the system to forget things but I can't
help but recoil at a system that mandates the destruction of the work
put into it.
As a publisher why would this be desirable? I would want to control my
work's lifecycle, not have the medium control it.
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.
As a server operator/implementor I could decide to ignore those parts
of the spec, always report a difficulty factor of 0.0, and never honor
a ttl, and accept a payload of any size.
Then you'd probably never be invited to a realm of servers, or they
would refuse to accept any items you try to share.
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.
I'll be interested to see where this goes.
It's fun to think about at least!
Parent:
Start of thread:
"Specifying Spring ‘83" (by Gustaf Erikson <gerikson@gmial.com> on Sun, 12 Jun 2022 15:00:43 +0200)
Children:
Re: "Specifying Spring ‘83" (by sean@conman.org on Tue, 14 Jun 2022 07:40:31 -0000 (UTC))