Tough changes to keep gwit simple

Lately I've been updating the gwit specification to fix several issues that have surfaced during private mail exchanges and discussions with people who I consider relevant in the fields of Gemini and decentralized publishing. First, I want to thank each of them for their help and the time and effort that they have devoted to this, and for their very valuable input! 🖖 Also note that the "gwit-spec" mailing list is always open for further public discussion.

Discussion list for the gwit specification

While many of the changes are relatively minor, I've had to face some others with a deeper impact, where overall simplicity seemed at odds with author convenience. It's been very tempting to lean towards a (probably false) sense of usability that may attract more people towards gwit, at the cost of increased system complexity and fragility. These have been tough decisions, but in the end I feel that sticking to gwit's design goals will prove right in the long term.

gwit's design goals

I believe it's important to remind oneself of these goals. First the functional goals:

Clear target: lightweight, static sites (mostly text) with internal and external hyperlinks.

Content authentication: it should be possible to verify content authorship and integrity.

Hosting independence: sites should not be bound to a specific host or location.

Content replication: sites should be easy to copy in their entirety.

Privacy: browsing should leak as little information as possible to external parties.

Content sharing: copies of sites should be easy to share in their entirety.

Offline-first: some browsing (esp. in-site) should be possible regardless of connectivity.

Content independence: any content type should be supported (although certain ones may be preferred that match the other goals).

File compatibility: content should be accessible as plain files.

Content history: past versions of sites should be available; exact versions should be addressable.

Forgiveness: site authors should be able to remove or change content permanently if they change their minds.

Transport independence: retrieving site content should not be tied to a specific network protocol.

Compatibility: it should be easy to publish an existing static site (esp. Web and Gemini) as a gwit site.

Small-scale discoverability: finding other sites should be possible without resorting to external services.

And the architectural goals:

Simplicity and human scale: simple enough to be fully understood and implemented by a single person in reasonable time.

Humanism above techno-solutionism: issues with a complex technical solution should be left to human interaction.

Long-term readiness: minimally usable after decades, or when platforms no longer support specific tools.

Graceful degradation: minimally usable in the face of failing components (like connectivity or software); e.g. via files.

Architectural minimalism: avoid complex or unnecessary dependencies.

Frugality in resource usage: esp. power consumption (because of complex computations, large memory footprint, or intensive network traffic).

Feature minimalism: only provide the features needed to cover functional goals.

Ease of adoption: prefer common, existing knowledge over new or complex concepts.

Friendliness and transparency: no compulsory abstractions that hide complexity.

Feature stability: focus on intended usage and avoid constant extensions to functionality.

It's not easy to stick to such radical principles when designing a software system, and not fall for endless flexibility and apparent friendliness. This reminds me of the latest updates to the Gemini FAQ and the reasons behind such peculiar but powerful decisions in protocol design.

Project Gemini FAQ - §4 Protocol design (see point 4.2)

With more changes to come soon (like splitting and reorganizing the spec), I hope that gwit's design goals will always help make the right choices.

🍃

🗒️ Back to log index