Update

3d_rendering.md

@@ -4,15 +4,54 @@ In [computer graphics](graphics.md) 3D rendering is the process of computing ima
 
 There are many methods and [algorithms](algorithm.md) for doing so differing in many aspects such as computation complexity, implementation complexity, realism of the result, representation of the 3D data, limitations of viewing and so on. If you are just interested in the [realtime](realtime.md) 3D rendering used in [gaymes](game.md) nowadays, you are probably interested in [GPU](gpu.md)-accelerated 3D [rasterization](rasterization.md) with [APIs](api.md) such as [OpenGL](opengl.md) and [Vulkan](vulkan.md).
 
-[LRS](lrs.md) has a 3D rendering library called [small3dlib](small3dlib.md).
+[LRS](lrs.md) has a simple 3D rendering library called [small3dlib](small3dlib.md).
 
 ## Methods
 
 As most existing 3D "[frameworks](framework.md)" are [harmful](harmful.md), a [LRS](lrs.md) programmer is likely to write his own 3D rendering system that suits his program best, therefore we should list some common methods of achieving 3D. Besides that, it's just pretty interesting to see what there is in the store.
 
-**Rendering spectrum**: The book *Real-Time Rendering* mentions that methods for 3D rendering can be seen as lying on a spectrum, one extreme of which is *appearance reproduction* and the other *physics simulation*. Methods closer to trying to imitate the appearance try to simply focus on imitating the look of an object on the monitor that the actual 3D object would have in real life, without being concerned with *how* that look arises in real life -- these may e.g. use image data such as photographs; these methods may rely on lightfields, photo [textures](texture.md) etc. The physics simulation methods try to replicate the behavior of light in real life -- their main goal is to solve the **[rendering equation](rendering_equation.md)**, usually only [approximately](approximation.md) -- and so, through internally imitating the same processes, come to similar visual results that arise in real world: these methods rely on creating 3D geometry (e.g. that made of triangles or voxels), computing light reflections and [global illumination](global_illumination.md). Most methods lie somewhere in between these two extremes: for example [billboards](billboard.md) and [particle systems](particle_system.md) may use a texture to represent an object while at the same time using 3D quads (very simple 3D models) to correctly deform the textures by perspective and solve their visibility. The classic polygonal 3D models are also usually somewhere in between: the 3D geometry and [shading](shading.md) are trying to simulate the physics, but e.g. a photo texture mapped on such 3D model is the opposite appearance-based approach ([PBR](pbr.md) further tries to shift the use of textures more towards the *physics simulation* end).
+A very important realization of a graphics programmer is that **3D rendering is to a great extent about [faking](cheating.md)** (especially the mainstream realtime 3D) -- it is an endeavor that seeks to produce something that looks somehow familiar to HUMAN sight specifically and so even though the methods are mathematical, the endeavor is really an [art](art.md) in the end, not dissimilar to that of a magician who searches for "smoke and mirrors" [hacks](hacking.md) to produce illusions for the audience. Reality is infinitely complex, we use nothing else but [approximations](approximation.md) and neglecting that rely on assumptions about human sight such as "60 FPS looks like smooth movement to human eye", "infrared spectrum is invisible", "humans can't tell a mirror reflection is a bit off", "inner corners are usually darker than flat surfaces", "no shadow is completely black because light scatters in the atmosphere" etc. Really 3D graphics is nothing but searching for what looks [good enough](good_enough.md), and deciding this relies on a SUBJECTIVE judgement of a human (and sometimes every individual). In theory -- if we had infinitely powerful computers -- we would just program in a few lines of electromagnetic equations and run the precise simulation of light propagating in 3D environment to produce an absolutely realistic result, but though some methods try to come close to said approach, we simply won't ever have infinitely powerful computers. For this we have to resort to a bit more [ugly](ugly.md) approach of identifying specific notable real-life phenomena individually (for example [caustics](caustic.md), [Fresnel](fresnel.md), mirror reflections, refractions, [subsurface scattering](subsurface_scattering.md), metallicity, [noise](noise.md), [motion blur](motion_blur.md) and myriads of others) and addressing each one individually with special treatment, many times correcting and masking our imperfections (e.g. applying [antialiasing](antialiasing.md) because we dared to use a simplified model of light sampling, applying texture filtering because we dared to only use finite amount of memory for our data, applying [postprocessing](postprocessing.md) etc.).
 
-A table of some common 3D rendering methods follows, including the most simple, most advanced and some unconventional ones. Note that here we talk about methods and techniques rather than algorithms, i.e. general approaches that are often modified and combined into a specific rendering algorithm. For example the traditional triangle rasterization is sometimes combined with raytracing to add e.g. realistic reflections. The methods may also be further enriched with features such as [texturing](texture.md), [antialiasing](antialiasing.md) and so on. The table below should help you choose the base 3D rendering method for your specific program.
+**Rendering spectrum**: The book *Real-Time Rendering* mentions that methods for 3D rendering can be seen as lying on a spectrum, one extreme of which is *appearance reproduction* and the other *physics simulation*. Methods closer to trying to imitate the appearance try to simply focus on imitating the look of an object on the monitor that the actual 3D object would have in real life, without being concerned with *how* that look arises in real life (i.e. closer to the "faking" approach mentioned above) -- these may e.g. use image data such as photographs; these methods may rely on lightfields, photo [textures](texture.md) etc. The physics simulation methods try to replicate the behavior of light in real life -- their main goal is to solve the **[rendering equation](rendering_equation.md)**, still only more or less [approximately](approximation.md) -- and so, through internally imitating the same processes, come to similar visual results that arise in real world: these methods rely on creating 3D geometry (e.g. that made of triangles or voxels), computing light reflections and [global illumination](global_illumination.md). This is often easier to program but more computationally demanding. Most methods lie somewhere in between these two extremes: for example [billboards](billboard.md) and [particle systems](particle_system.md) may use a texture to represent an object while at the same time using 3D quads (very simple 3D models) to correctly deform the textures by perspective and solve their visibility. The classic polygonal 3D models are also usually somewhere in between: the 3D geometry and [shading](shading.md) are trying to simulate the physics, but e.g. a photo texture mapped on such 3D model is the opposite appearance-based approach ([PBR](pbr.md) further tries to shift the use of textures more towards the *physics simulation* end).
+
+With this said, let's not take a look at possible **classifications** of 3D rendering methods. As seen, there are many ways:
+
+- by **order**:
+  - **object order**: The method iterates on objects and draws object by object, one after another. This results in pixels being drawn to "random" places on the screen and possibly already drawn pixels being [overdrawn](overdraw.md) with new pixels (though this can be further reduced). Typically requires a [frame buffer](frame_buffer.md) and [double buffering](double_buffering.md), often also [z-buffer](z_buffer.md) (or [sorting](sorting.md)), i.e. requires a lot of memory. This method is also a bit ugly but typically also faster than the alternative, so it is prevailing nowadays.
+  - **image order**: The method iterates on screen pixels, typically going pixel by pixel from left to right, top to bottom, deciding the color of each pixel independently. May be easier to program and require less memory (no frame buffer is needed, see e.g. [frameless rendering](frameless.md)), however though [parallelism](parallelism.md) is applicable here (many pixels may potentially be independently computed in parallel, speeding up rendering), the algorithms used (e.g. [path tracing](path_tracing.md)) often have to expensively simulate light behavior and so performance is still an issue.
+- by **speed**:
+  - **[realtime](realtime.md)**: Able to render at interactive [FPS](fps.md), typically used in [games](game.md) etc.
+  - **[offline](offline.md)**: Spends a lot of time (even many minutes) on rendering each frame with the goal to produce output of extreme quality, typically used to render 3D movies etc.
+- by **relative limitation**:
+  - **primitive/"pseudo3D"/2.5D/...**: Older methods that produce 3D views but had great limitations e.g. in camera degrees of freedom or possible environment geometry that was usually limited to a "2D sector map" (see e.g. [Doom](doom.md)).
+  - **full/"true" 3D**: The "new" way of 3D rendering that allows freely rotating camera, arbitrary 3D geometry etc. Though this still has limitations (as any computer approximation of reality), many people just call this the "true" 3D.
+- by **approach** (sides of above mentioned rendering spectrum):
+  - **appearance based**: Focuses on achieving desired appearance by any means necessary, faking, "cheating", not trying to stay physically correct. This is typically faster.
+  - **[physics](physics.md) simulation** (see also [physically based rendering](pbr.md)): Focuses on simulating the underlying physics of reality with high correctness so that we also get a very realistic result.
+- by **main method/algorithm** (see also the table below):
+  - **rasterization**: Appearance based object order methods further based on a relatively simple algorithm capable of drawing (rasterizing) a simple geometric shape (such as a triangle) which we then use to draw the whole complex 3D scene (composed of great many of triangles).
+  - **ray casting/tracing**: Physics simulation image order methods further based on tracing paths of light in a manner that's closer to reality.
+  - ...
+- by **3D data** ([vector](vector.md) vs [raster](raster.md) classification applies here just as in 2D graphics):
+  - **triangle meshes** (vector, and other boundary representations)
+  - **[voxels](voxel.md)** (raster, and potentially other volumetric representations)
+  - **[point clouds](point_cloud.md)**
+  - **[heightmaps](heightmap.md)**
+  - **[implicit surfaces](implicit_surface.md)**
+  - **smooth [surfaces](surface.md)** (e.g. [NURBS](nurbs.md))
+  - **2D sectors** (e.g. [Doom](doom.md)'s [BSP](bsp.md) "pseudo 3D" rendering)
+  - ...
+- by **[hardware](hw.md)**:
+  - **[software rendering](sw_rendering.md)**: Rendering only with [CPU](cpu.md). This is typically slower as a CPU mostly performs sequential computation, eliminating the possible parallelism optimization, however the approach is more [KISS](kiss.md) and [portable](portablity.md).
+  - **[GPU](gpu.md) accelerated**: Making use of specialized graphics rendering hardware (GPU) that typically uses heavy parallelism to immensely speed up rendering. While this is the mainstream, extremely fast way of rendering, it is also greatly [bloated](bloat.md) while often being an [overkill](overkill.md) that greatly complicates programming and makes programs less [portable](portability.md), less [future proof](future_proof.md) etc.
+- by **realism** of output:
+  - **[photorealistic](photorealism.md)**
+  - **stylized**, flat [shaded](shading.md), [wireframe](wireframe.md), ...
+  - ...
+- **[hybrids](hybrid.md)**: Methods may be combined and/or lie in between different extremes, for example we may see a rasterizer 3D renderer that uses ray tracing to add detail (shadows, reflections, ...) to the scene, we may see renderers that allow triangle meshes as well as voxels etc.
+- ...
+
+Finally a table of some common 3D rendering methods follows, including the most simple, most advanced and some unconventional ones. Note that here we talk about methods and techniques rather than algorithms, i.e. general approaches that are often modified and combined into a specific rendering algorithm. For example the traditional triangle rasterization is sometimes combined with raytracing to add e.g. realistic reflections. The methods may also be further enriched with features such as [texturing](texture.md), [antialiasing](antialiasing.md) and so on. The table below should help you choose the base 3D rendering method for your specific program.
 
 The methods may be tagged with the following:
 
@@ -30,6 +69,7 @@ The methods may be tagged with the following:
 |[BSP rendering](bsp.md)                   |*2.5D*, e.g. [Doom](doom.md)        |
 |[conetracing](conetracing.md)             |*IO off*                            |
 |"[dungeon crawler](dungeon_crawler.md)"   |*OO 2.5D*, e.g. Eye of the Beholder |
+|edge list, scanline, span rasterization   |*IO*, e.g. [Quake](quake.md) 1      |
 |ellipsoid rasterization                   |*OO*, e.g. Ecstatica                |
 |flat-shaded 1 point perspective           |*OO 2.5D*, e.g. Skyroads            |
 |reverse raytracing (photon tracing)       |*OO off*, inefficient               |
@@ -233,6 +273,4 @@ Let's see what a typical pipeline might look like, similarly to something we mig
 6. **Stage: pixel/fragment processing**: Each pixel (fragment) produced by rasterization is processed here by a [pixel/fragment shader](fragment_shader.md). The shader is passed the pixel/fragment along with its coordinates, depth and possibly other attributes, and outputs a processed pixel/fragment with a specific color. Typically here we perform [shading](shading.md) and [texturing](texture.md) (pixel/fragment shaders can access texture data which are again stored in texture buffers on the GPU).
 7. Now the pixels are written to the output buffer which will be shown on screen. This can potentially be preceded by other operations such as depth tests, as mentioned above. 
 
-
-
 TODO: example of specific data going through the pipeline

crypto.md

@@ -1,8 +1,8 @@
 # Cryptocurrency
 
-Cryptocurrency, or just *crypto*, is a digital, virtual (non-physical) currency used on the [Internet](internet.md) which uses [cryptographic](cryptography.md) methods (electronic signatures etc.) to implement a [decentralized](decentralized.md) system in which there is no authority to control the currency (unlike e.g. with traditional currencies that are controlled by the state or systems of digital payments controlled by the banks that run these systems). Cryptocurrencies use so called **[blockchain](blockchain.md)** as an underlying technology and are practically always implemented as [free and open-source software](foss.md). Example of cryptocurrencies are [Bitcoin](bitcoin.md), [Monero](monero.md) or [Dogecoin](dogecoin.md).
+Cryptocurrency, or just *crypto*, is a digital, [cryptofascist](cryptofascism.md) virtual (non-physical) [currency](money.md) used on the [Internet](internet.md) which uses [cryptographic](cryptography.md) methods (electronic signatures etc.) to implement a [decentralized](decentralization.md) system in which there is no authority to control the currency (unlike e.g. with traditional currencies that are controlled by the state or systems of digital payments controlled by the banks that run these systems). Cryptocurrencies traditionally use so called **[blockchain](blockchain.md)** as the underlying technology and are practically always implemented as [FOSS](foss.md). Example of cryptocurrencies are [Bitcoin](bitcoin.md), [Monero](monero.md) or [Dogecoin](dogecoin.md).
 
-The word *crypto* in *crpytocurrency* **doesn't imply that the currency provides or protects privacy** -- it rather refers to the cryptographic algorithms used to make the currency work -- even though thanks to the decentralization, anonymity and openness cryptocurrencies actually are mostly privacy friendly (up to the points of being considered the currency of criminals).
+The word *crypto* in *crpytocurrency* **doesn't imply that the currency provides or protects "[privacy](privacy.md)"** -- it rather refers to the cryptographic algorithms used to make the currency work -- even though thanks to the decentralization, anonymity and openness cryptocurrencies actually are mostly "privacy friendly" (up to the points of being considered the currency of criminals).
 
 [LRS](lrs.md) sees cryptocurrencies as not only unnecessary [bullshit](bullshit.md), but downright as an **unethical** technology because [money](money.md) itself is unethical, plus the currencies based on proof of work waste not only human effort but also enormous amount of electricity and computing power that could be spent in a better way. Keep in mind that **cryptocurrencies are part of [cryptofascism](cryptofascism.md)**; they're a way of digitizing harmful concepts existing in society. Crypto is just an immensely expensive game in which people try to fuck each other over money that have been stolen from the people.
 

doom.md

@@ -16,6 +16,7 @@ Some **[interesting](interesting.md) things** about Doom:
 
 - Someone created a Doom system monitor for [Unix](unix.md) systems called [psDooM](psdoom.md) where the monsters in game are the operating system [processes](process.md) and killing the monsters kills the processes.
 - Someone (kgsws) has been [hacking](hacking.md) the ORIGINAL Doom engine in an impressive way WITHOUT modifying the source code or the binary, rather using [arbitrary code execution](arbitrary_code_execution.md) bug; he added very advanced features known from newer source ports, for example an improved 3D rendering algorithms allowing geometry above geometry etc. (see e.g. https://yt.artemislena.eu/watch?v=RdbRPNPUWlU).
+- Doom sprites were made from photos of physical things: weapons are modified photos of toys, enemies were made from clay and then photographed from multiple angles (actually a great alternative to [3D modeling](3d_model.md) that's less dependent on computers and produces more realistic results).
 - TODO
 
 ## Doom Engine/Code
@@ -26,7 +27,7 @@ Doom source code is written in [C89](c.md) and is about 36000 [lines of code](lo
 
 The game only used [fixed point](fixed_point.md), no [float](float.md)!
 
-The **Doom engine** was revolutionary and advanced (not only but especially) video game graphics by a great leap, considering its predecessor [Wolf3D](wolf3D.md) was really primitive in comparison (Doom basically set the direction for future trends in games such as driving the development of more and more powerful [GPUs](gpu.md) in a race for more and more impressive visuals). Doom used a technique called **[BSP rendering](bsp.md)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). No [GPU](gpu.md) acceleration was used, graphics was rendered purely with [CPU](cpu.md) (so called [software rendering](sw_rendering.md), GPU rendering would come with Doom's successor [Quake](quake.md), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D", some retards took this even as far as calling Doom 2D with its graphics being just an "illusion", as if literally every 3D graphics ever wasn't a mere illusion. Nevertheless, though with limitations, Doom did present 3D views and internally it did work with 3D coordinates (for example the player or projectiles have 2D position plus height coordinate), despite some dumb YouTube videos saying otherwise. For this reason we prefer to call Doom a **primitive 3D** engine, but 3D nonetheless. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke_3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
+The **Doom engine** (also called *id Tech 1*) was revolutionary and advanced (not only but especially) video game graphics by a great leap, considering its predecessor [Wolf3D](wolf3D.md) was really primitive in comparison (Doom basically set the direction for future trends in games such as driving the development of more and more powerful [GPUs](gpu.md) in a race for more and more impressive visuals). Doom used a technique called **[BSP rendering](bsp.md)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). No [GPU](gpu.md) acceleration was used, graphics was rendered purely with [CPU](cpu.md) (so called [software rendering](sw_rendering.md), GPU rendering would come with Doom's successor [Quake](quake.md), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D", some retards took this even as far as calling Doom 2D with its graphics being just an "illusion", as if literally every 3D graphics ever wasn't a mere illusion. Nevertheless, though with limitations, Doom did present 3D views and internally it did work with 3D coordinates (for example the player or projectiles have 2D position plus height coordinate), despite some dumb YouTube videos saying otherwise. For this reason we prefer to call Doom a **primitive 3D** engine, but 3D nonetheless. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke_3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
 
 Indexed ([palette](palette.md)) mode with "only" 256 colors was used for rendering. Precomputed color tables were used to make dimming of colors faster.
 

gemini.md

@@ -3,3 +3,9 @@
 Gemini is a [shitty](shit.md) [pseudominimalist](pseudominimalism.md) network [protocol](protocol.md) for publishing, browsing and downloading files, a simpler alternative to the [World Wide Web](www.md) and a more complex alternative to [gopher](gopher.md) (by which it was inspired). It is a part of so called [Smol Internet](smol_internet.md). Gemini aims to be a "[modern](modern.md) take on gopher", adding some new "features" and a bit of [bloat](bloat.md). The project states it wants to be something in the middle between Web and gopher but doesn't want to replace either.
 
 On one hand Gemini is kind of cool but on the other hand it's pretty [shit](shit.md), especially by REQUIRING the use of [TLS](tls.md) [encryption](encryption.md) for "muh security" because the project was made by privacy freaks that advocate the *ENCRYPT ABSOLUTELY EVERYTHIIIIIING* philosophy. This is firstly mostly unnecessary (it's not like you do Internet banking over Gemini) and secondly adds a shitton of [bloat](bloat.md) and prevents simple implementations of clients and servers. Some members of the community called for creating a non-encrypted Gemini version, but that would basically be just gopher. Not even the Web goes as far as REQUIRING encryption (at least for now), so it may be better and easier to just create a simple web 1.0 website rather than a Gemini capsule. And if you want ultra simplicity, we highly advocate to instead prefer using [gopher](gopher.md) which doesn't suffer from the mentioned issue.
+
+## See Also
+
+- [gopher](gopher.md)
+- [smol internet](smol_internet.md)
+- [Fediverse](fediverse.md)

gopher.md

@@ -21,3 +21,9 @@ For now take a look at stuff in this repo: `git clone git://bitreich.org/gopher-
 ## Example
 
 TODO
+
+## See Also
+
+- [gemini](gemini.md)
+- [Fediverse](fediverse.md)
+- [smol internet](smol_internet.md)

smol_internet.md

@@ -3,3 +3,7 @@
 Smol Internet, smol web, small web, smol net, dork web, poor man's web, web revival, web 1.0 and similar terms refer to Internet technology (such as [gopher](gopher.md), [gemini](gemini.md), plain [HTML](html.md) etc.) and communities that are smaller, [simpler](kiss.md), less controlled and less [toxic](toxic.md) than the "big mainstream Internet" (especially the [Web](www.md)) which due to [capitalism](capitalism.md) became littered with [shit](shit.md) like [ads](marketing.md), unbearable [bloat](bloat.md), censorhip, [spyware](spyware.md), corporate propaganda, masses of [retarded people](influencer.md), [bullshit](bullshit.md) cheap visuals like animations etc. Consider this analogy: the mainstream, i.e. [world wide web](www.md), [Discord](discord.md), [Facebook](facebook.md) etc., is like a big shiny city, but as the city grows and becomes too stressful, overcrowded, hasted, overcontrolled with police and ads on every corner, people start to move to the countryside where life is simpler and happier -- smol Internet is the countryside.
 
 What EXACTLY constitutes a Smol Internet? Of course we don't really have exact definitions besides what people write on blogs, it also depends on the exact term we use, e.g. smol web may refer specifically to lightweight self-hosted websites while smol net will also include different protocols than [HTTP(s)](http.md) (i.e. things outside the Web). But we are usually talking about simpler ([KISS](kiss.md), [suckless](suckless.md), ...), alternative, [decentralized](decentralization.md), [self hosted](self_hosting.md) technology (protocols, servers, ...), and communities that strive to escape commercially spoiled spaces. These communities don't aim to grow to big sizes or compete with the mainstream Web, they do not seek to replace the Web or achieve the same things (popularity, profitability, ...) but rather bring back the quality the Web (and similar services such as [Usenet](usenet.md)) used to have in the early days such as relative freedom, unrestricted sharing, free speech, simplicity, decentralization, creative personal sites, comfiness, [fun](fun.md) and so on. It is for the people, not for companies and corporations. Smol Internet usually refers to [gopher](gopher.md) and [gemini](gemini.md), the alternative protocols to [HTTP](http.md), the basis of the Web. Smol Web on the other hand stands for simple, plain [HTML](html.md) web 1.0 static personal/community sites on the Web itself which are however hosted independently, often on one's own server (self hosted) -- such sites can be searched e.g. with the [wiby](wiby.md) search engine. It may also include small communities such as [pubnixes](pubnix.md) like [SDF](sdf.md) and [tildeverse](tildeverse.md). Other KISS communication technology such as [email](email.md) and [IRC](irc.md) may also fall under Smol Internet.
+
+## See Also
+
+- [Fediverse](fediverse.md)