[Oberon] [SPAM | WERBUNG] Re: Simplification & complexification; was, Oberon Text and new systems;

[նորայր]

speaking of this, take a look at Spartan and Gemini protocols.
Gemini has no client side scripting, no way of fingerprinting the client, no password (but only key based) authentication, extremely simple gemtext format. The specs are designed in a way that "anyone" could implement a client or server in a couple of days.

I do spend most of my internet time in so called geminispace and by using XMPP. http(s) is not the majority of internet traffic from my workstation. if I use http, or some of my internet friends create software that delivers content via http, I ask them to make sure js is not strictly required for core functionality and to test the website with simple browsers like lynx, links, netsurf, dillo.
 
by the way, it's not my main focus, but from time to time i am doing something in a direction of achieving modern TLS and Gemini browser in Oberon.

For example, 

* i have an RSA implementation that works (but it is currently problematic in case of big numbers, because of Oberon's only signed types.

* i have added Spartan and Gemini protocol components to Indy (Internet Direct components for Delphi and FreePascal) - no pull request yet, because i can't figure out how to update the icons on component palette.

* i have Spartan and Gemini implementations that work with voc (vishap oberon compiler) by using mbedtls 2 library (need to migrate to mbedtls 3). so  it's not native TLS written in Oberon, it's a wrapper to mbedtls. but i believe we need native TLS implementation.

(initially mbedtls wrapper was created in order to add functionality to download files via https to vipak package manager). 

some of the oberon projects are published on https://github.com/norayr - on the main page. there's RSA in Oberon I have mentioned and let's say a VPN proof of concept in Oberon.

On 29 Oct 2025 10:05:30 -0700
peter at easthope.ca wrote:

> From: schierlm at gmx.de (Michael Schierl)
> Date: Tue, 8 Jun 2021 23:02:57 +0200
> > The most complex application on most "smaller" OSes today is the Web
> > browser. And even when they are several megabytes large, they cannot
> > adequately parse what "HTML5" has become today (even if you exclude
> > JavaScript).
> > ...
> > So, I would not try to provide any (badly compatible) HTML5 support to a
> > system like Oberon which tries to be simple and tries to remove what can
> > be removed.
> 
> Acknowledged, yet I'm not willing to be completely apathetic in 
> response to growing complexification.  Therefore working on a specific 
> petition to the Canadian House of Commons.  Description here. 
> https://dev1galaxy.org/viewtopic.php?id=7487
> 
> I know this isn't Oberon specific.  Definitely is relevant to 
> simplification.
> 
> To make the petition viable I need to find five residents of Canada 
> willing to support it.  When I have five supporters, will ask my M.P.
> Elizabeth May to authorize it. The name and address of each supporter 
> will then be submitted to the Clerk of Petitions in Ottawa.
> 
> I'm interested to hear from anyone willing to volunteer support.
> 
> Thanks,                           ... Peter E.
> 
> -- 
> mobile:  +1 778 951 5147 <= still working
> VoIP:    +1 778 508 0020 <= new & working
> projects: en.wikibooks.org/wiki/User:PeterEasthope
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon


-- 
There are two ways of constructing a software design.  One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

-- C.A.R. Hoare

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20251030/23d9495e/attachment.sig>