💾 Archived View for gemi.dev › gemini-mailing-list › 001034.gmi captured on 2023-11-04 at 13:16:57. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

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

[off-topic] [tech] talkat

mbays <mbays (a) sdf.org>

Apologies to those who already saw my glogposts on this. Nothing much 
new here.

I've been thinking for a while that it should be possible to repeat 
Gemini's trick of updating a classic protocol (gopher) to take into 
account the realities of the modern internet -- its international 
character, meaning unicode support is essential, and mass surveillance, 
meaning solid encryption and authentication are also necessary -- while 
aiming for maximal simplicity, and keeping it inextensible to avoid the 
potential for future complexity.

A couple of months ago, I realised that unix talk would make a great 
candidate for this kind of update, and now I've completed my attempt at 
that. Like gemini, it consists of little more than TLS+UTF8.

=> gemini://gemini.thegonz.net/talkat/spec.gmi Spec
=> gemini://gemini.thegonz.net/htalkat/ Implementation in Haskell

Maybe people here could be interested in playing with it, picking holes 
in it, or even writing their own implementations. All would be welcome!

Meanwhile, any thoughts on what else could do with geminification?

Link to individual message.

Jacob Stewart <jacob.stewart (a) tutamail.com>

>If no client certificate is presented, the server MUST reject the 
connection.>The server and client certificates are intended to identify 
the individual users involved.
What if the server operator wants to operate an anonymous chat?

-- 
Securely sent with Tutanota.
Get your own encrypted, ad-free mailbox at?https://tutanota.com.
https://fastmail.fm is not encrypted but has some privacy.
You can search for more providers.

Link to individual message.

Chris Brannon <chris (a) the-brannons.com>

Jacob Stewart <jacob.stewart at tutamail.com> writes:

>>If no client certificate is presented, the server MUST reject the
> connection.
>>The server and client certificates are intended to identify the individual
> users involved.
> What if the server operator wants to operate an anonymous chat?

Nothing prevents you from generating a one-time cert, having multiple
pseudonymous certs corresponding to various assumed identities, etc
etc.  With client certs we can have both authentication and
pseudonymity.

-- Chris

Link to individual message.

mbays <mbays (a) sdf.org>



>Jacob Stewart <jacob.stewart at tutamail.com> writes:
>
>>>If no client certificate is presented, the server MUST reject the 
>>>connection.
>>>The server and client certificates are intended to identify the 
>>>individual users involved.
>> What if the server operator wants to operate an anonymous chat?
>
>Nothing prevents you from generating a one-time cert, having multiple
>pseudonymous certs corresponding to various assumed identities, etc
>etc.  With client certs we can have both authentication and
>pseudonymity.

Exactly. In the htalkat implementation, you select an identity (or 
create a new one) by using the -d option or HTALKAT_DIR environment 
variable.

It's also easy to run as a tor hidden service, for additional anonymity.

Link to individual message.

---

Previous Thread: Gemini Newsgroup RFD

Next Thread: Video: Why Gemini?