Intro: <https://www.robinsloan.com/lab/specifying-spring-83/>
Spec:
<https://github.com/robinsloan/spring-83-spec/blob/main/draft-20220609.md>

A proposed new protocol with the following features:

- each item is limited to 2,217 bytes
- items can contain HTML and CSS
- items are cryptographically signed
- global number of items are limited to 10E6
- servers store and forward, and must thus be able to host all items -
hence the size limit, to allow low-end VPS to participate

I'm interested in what the Gemini community thinks of this!

/g.

--
#include SIG

On Sun, 12 Jun 2022 15:00:43 +0200, Gustaf Erikson wrote:
> Intro: <https://www.robinsloan.com/lab/specifying-spring-83/>
> Spec:
><https://github.com/robinsloan/spring-83-spec/blob/main/draft-20220609.md>
>
> A proposed new protocol with the following features:
>
> - each item is limited to 2,217 bytes
> - items can contain HTML and CSS
> - items are cryptographically signed
> - global number of items are limited to 10E6
> - servers store and forward, and must thus be able to host all items -
> hence the size limit, to allow low-end VPS to participate

At the start I found the idea interesting, though as I read the intro and
specification I started to ask 'why do I care and what does this actually
solve' a lot.

Technically it feels like something you could build as a reasonably simple
client/server web application. Some JavaScript for the client and a simple
CGI-or-similar on the server. The whole transport layer looks very RESTful
to me (seems like this was on purpose). Though it is perfectly reasonable
thus far I start asking 'what are we really trying to solve here' at this
point.

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.

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.

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.

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.

It is also worth mentioning that one of the things about the 'ancient'
Internet protocols that I believe make them so successful is their
ability to continue to adapt to the new landscape around them. News and
e-mail pre-date TCP/IP as the defacto transport protocol for the network
and at least for e-mail there have been hundreds of projects involving
thousands of engineers trying to replace them since the web was born.
One can argue about the viability of netnews these days but as far as
e-mail goes, MUAs just get expanded to do more and the efforts to replace
it end up in the dustbin of history.

I'll be interested to see where this goes.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

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!

It was thus said that the Great Gustaf Erikson <gerikson@gmial.com> once stated:
>
> 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.

A close reading of the spec:

The client must not:

execute any JavaScript included in the board
load any images, media, or fonts linked by the board

It seems to only want to allow HTML be loaded and that's it.

-spc

sean@conman.org writes:

> It was thus said that the Great Gustaf Erikson <gerikson@gmial.com> once stated:
>>
>> 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.
>
> A close reading of the spec:
>
> The client must not:
>
> execute any JavaScript included in the board
> load any images, media, or fonts linked by the board
>
> It seems to only want to allow HTML be loaded and that's it.

Thanks for the correction!

However, nothing is stopping the client displaying the board from
tracking loads, interactions (clicks &c.) and other activity and
reporting that. It's analogous to podcast players in that regard. RSS
doesn't really have tracking but there are ways around it.

Reverting back to Gemini, nothing prevents a client from recording its
users' activity and "phoning home" with the data. It's just that such a
client is unlikely to be very popular among current Gemini users.

/g.

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