💾 Archived View for gemi.dev › gemini-mailing-list › 000596.gmi captured on 2023-12-28 at 15:49:46. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

-=-=-=-=-=-=-

[announce] Gemini in 2021

1. Solderpunk (solderpunk (a) posteo.net)

Happy New Year, Geminauts!

This seems like a good opportunity to make the maiden post to the
[announce] topic.

None of you need to be reminded that 2020 was an eventful and unusual
year, and the situation was no different in Geminispace!  While
obviously a new internet protocol of deliberately humble scope is not
remotely as important as the other issues which defined last year, at
least there was one small part of our lives where the events of 2020
were, on the whole, very positive.

At the start of the year, Gemini was around six months old and still a
fairly small and quiet project.  But starting around May we hit Hacker
News and other high profile social sites multiple times, resulting in an
explosive growth of interest in and discussion about the protocol.  Not
all of it was positive, but nevertheless by the year's end the ecosystem
had expanded significantly.  Many new software implementations, servers,
services and users joined this fledgling space in 2020, and there are no
signs of this growth slowing down.  It's been tremendously gratifying
for me to see so many people embrace the ideas and philosophy of Gemini.
The project has grown larger than I ever expected, faster than I ever
expected.  Lots of people have written me very kind emails of thanks,
saying that the internet feels more fun for them than it has in decades,
and each one has made me very happy.

This success has been a bit of a double-edged sword, though.  The
demands on my time and attention as Benevolent Dictator of the project
have grown beyond what's sustainable, and the model of using a single,
unmoderated mailing list as a venue for any and all discussion of all
aspects of the project is really starting to strain at the edges.  I am
hoping to make a number of changes to the project early in 2021 to
provide some much needed relief to the entire community, and I'd like
to roughly outline my plans in this email.

On the technical side, the protocol specification is rapidly moving
toward a stage where there are no further major changes or
clarifications to make.  I hope that sometime this month it will be
possible to effectively finalise the current "speculative specification"
document.  At this point, the [spec] topic of the mailing list will be
retired, and the project will transition to a new phase where the
primary ongoing technical activity is to translate that speculative
specification into a more precise and formal technical document, with
the goal that it might eventually be submitted to formal internet
standard organisations like IETF and IANA.

This translation process is important, but not, I would argue, urgent or
even terribly interesting for most people involved in Gemini more
broadly.  Protocol specifications *should* be precise and formal, but
what we have currently is, empirically speaking, clearly good enough to
facilitate reliable inter-operability between implementations.  Gemini
has an astonishing breadth of client and server implementations for such
a young protocol, with clients available for every major platform,
including mobile devices, and at least in my experience everything works
together very nicely indeed.  We should be very proud of this
accomplishment!  It shouldn't be necessary for anybody but the most
interested of hardcore protocol geeks to follow the translation process
closely while it happens.  From the point of view of most developers,
the project should be considered more or less "done" very soon.

I don't yet know exactly how the translation process will happen.  I
certainly don't want to do it alone, and I expect I will gladly delegate
a lot of the work, while still remaining involved.  I want the process
to be publically visible, but not necessarily open to unbounded public
participation, like the initial design of the protocol was.  Very little
actual technical decision making should be involved in this translation
process.  If the attempt to formalise the specification reveals
additional small inconsistencies or ambiguities, these will be resolved
with the smallest possible changes and with concern for compatibility
with existing practices.

If you have previous experience working with IETF and/or IANA and you
feel like you might like to be involved in some stage of this process,
please feel free to reach out to me off-list.

On a more community-oriented note, I would also like to overhaul the
project's public face and delegate some of the responsibility of
managing it.  I plan to transition the project to a new domain this
year, rather than stick with gemini.circumlunar.space.  That domain was
only used because I already owned circumlunar.space for other purposes.
I would like to separate the two projects more, and give Gemini an
easier to remember domain which is more closely tied to its own
identity.  Naturally I will maintain redirects from the old domain for
a long time - this is exactly what redirects in Gemini were intended to
allow.  It would be great if exactly the same information was available
simultaneously over Gopher, Gemini and HTTPS, if this information was
better organised and curated than it is currently, and if documents
like the FAQ were translated into other languages.  It would be great if
there was an easier way for people to submit or suggest changes,
corrections, translations, etc. than sending email to a single point of
contact.

I don't, frankly, really know what the easiest way to achieve this is.
If you have ideas, and especially if you are willing to donate time or
resources to help, feel free to reach out to me off-list.  I would very
much like the solution not to involve any commercial services, such as
GitHub, and naturally the HTTPS version of the site should be totally
free of cookies, Javascript, analytics, etc.  Probably it should just be
derived directly from the Gemini version of the site using a tool like
Kineto (https://sr.ht/~sircmpwn/kineto/).  I don't mind at all if the
styling of the site is something a little "nicer" than what's there now,
as long as it remains clean, uncluttered, accessible and consists of a
single short stylesheet, and once the new framework is in place I am
happy for people who want to volunteer a design to reach out to me to do
so.

Obviously, having any kind of control over the project's public sites is
a high-trust position and I'd be much happier delegating this to
somebody with whom I've already had some interaction in the past and who
has displayed some clear commitment to the project.

If you'd like to volunteer to translate the FAQ or Best Practices
document into another language, please reach out to me off-list.  I'm
happy to start including these translations in the current version of
the site even before the transition to whatever new approach hopefully
emerges.

If you'd like to volunteer to play some role in moderating the mailing
list to help make it more a welcoming and civil place in the future,
please feel free to reach out to me off-list.  I don't know yet whether
this might involve actually assigning some degree of admin rights to
people or just having people keep a close eye on things and alert me if
they think things are getting out of hand.  But something will need to
be put in place, as I personally absolutely cannot maintain an
indefinite close eye on the entire list.

While I've outlined a lot of changes and work for the project's official
public presence, I also want to emphasise my belief that as Geminispace
continues to grow larger and faster, and as the protocol moves toward
technically maturity, there is actually less and less need for a single,
central, official public presence, and that the realistic scope of such
a presence becomes smaller and smaller.  Neither the web nor Gopher have
any such presence.  That's not to say there isn't material available
over either protocol to introduce newcomers, explain the protocol's
technical or philosophical underpinnings or point people toward popular
and/or new content.  Instead, that important content is distributed
across many locations and is produced and maintained by the community at
large.  I see no reason that Gemini should be any different.  Obviously
we're not quite at the same stage as either of those protocols, but
still, I expect that by the end of 2021 the official site will have
moved into a fairly static state, and continued community-building
activities will take place elsewhere.

Finally, I want to say a big thank you to every single person who played
a role large or small in 2020 in helping to spread awareness of Gemini,
in steering the design of the protocol, in writing software of any kind,
in setting up servers or, most importantly of all, in writing content.
We have come a long way in a short time and I look forward to us
maintaining this energy in the new year.

Cheers!
Solderpunk

Link to individual message.

2. cage (cage-dev (a) twistfold.it)

On Fri, Jan 01, 2021 at 07:07:45PM +0100, Solderpunk wrote:
> Happy New Year, Geminauts!

Happy new year to everyone! :)

[...]

> if documents
> like the FAQ were translated into other languages.

Even if my English is not exactly perfect, :) I could help translating
the FAQ in Italian.

Bye!
C.

Link to individual message.

3. Petite Abeille (petite.abeille (a) gmail.com)



> On Jan 1, 2021, at 19:07, Solderpunk <solderpunk at posteo.net> wrote:
> 
> translate that speculative specification into a more precise and formal 
technical document

Tangentially related:

How to Stop Endless Discussions
https://candost.blog/how-to-stop-endless-discussions/

? ???

Link to individual message.

---

Previous Thread: [ANN] Gneto, a personal Gemini to HTTP proxy server

Next Thread: [spec] Possible Tables Syntax