feat(finger); draft1

3 files changed, 426 insertions, 0 deletions

diff --git a/assets/more/bookmarks.yml b/assets/more/bookmarks.yml
index a140773..3440e54 100644
--- a/assets/more/bookmarks.yml
+++ b/assets/more/bookmarks.yml
@@ -61,3 +61,7 @@ bookmarks:
   title: The 88x31 GIF Collection
   date: '2024-11-26'
   host: textfiles.com
+- url: https://news.slashdot.org/story/24/11/28/1831249/coffee-at-highest-price-in-47-years
+  title: Coffee at Highest Price in 47 years - Slashdot
+  date: '2024-11-28'
+  host: news.slashdot.org
diff --git a/content-org/finger.org b/content-org/finger.org
new file mode 100644
index 0000000..ef5f456
--- /dev/null
+++ b/content-org/finger.org
@@ -0,0 +1,210 @@
+#+TITLE: Unix history#+AUTHOR: Michał Sapka
+#+URL: https://michal.sapka.me/unix-history/
+#+STARTUP: show2levels indent logdone
+
+#+HUGO_BASE_DIR: ~/ghq/michal.sapka.me/mms/site
+#+HUGO_WEIGHT: auto
+#+HUGO_SECTION: projects
+
+* Chotto                                                          :@projects:
+:PROPERTIES:
+:EXPORT_HUGO_SECTION: projects/finger
+:END:
+
+** DONE Finger
+CLOSED: [2024-11-13 Wed 00:10]
+:PROPERTIES:
+:EXPORT_FILE_NAME: _index
+:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :abstract A different type of social network
+:END:
+
+*** Fingersoc
+
+----
+
+Status: DRAFT
+
+**** Introduction
+
+<name> is a uni-directional, distributed, read-only social network.
+
+***** Name
+
+The inspiration comes from the =finger= protocol, where users of Unix systems could =finger(1)= other users to get some basic information aboout them.
+<name> tries to take that idea and allow it's usage in modern, interconnected internet.
+
+***** Requirement
+
+This memo follows the standard requirements of an RFC.
+To quite the RFC1288:
+#+begin_quote
+   In this document, the words that are used to define the significance
+   of each particular requirement are capitalized.  These words are:
+
+   * "MUST"
+
+      This word or the adjective "REQUIRED" means that the item is an
+      absolute requirement of the specification.
+
+   * "SHOULD"
+
+      This word or the adjective "RECOMMENDED" means that there may
+      exist valid reasons in particular circumstances to ignore this
+      item, but the full implications should be understood and the case
+      carefully weighed before choosing a different course.
+
+   * "MAY"
+
+      This word or the adjective "OPTIONAL" means that this item is
+      truly optional.  One vendor may choose to include the item because
+      a particular marketplace requires it or because it enhances the
+      product, for example; another vendor may omit the same item.
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST requirements.  An implementation that satisfies all the
+   MUST and all the SHOULD requirements is said to be "unconditionally
+   compliant"; one that satisfies all the MUST requirements but not all
+   the SHOULD requirements is said to be "conditionally compliant".
+#+end_quote
+
+**** Use of <name>
+
+To use <name>, you need to understand three words:
+
+*Publisher* - he who publishes information on the <name>
+
+*Reader* - a human reading information published by a publisher.
+
+*Client* - a computer program for reading data on the <name> and presenting it to a reader.
+
+***** Publisher
+
+A published MAY be, either a human, or an automated process.
+Each published NEEDS to be able to publish files under URL accessible via HTTP(s).
+A publisher MAY be able to to it under any URL, be it either via manually updating files or with use of some automated process.
+
+A publisher SHOULD have a dedicated URL, like
+
+https://useronfirr.com/
+
+or
+
+https://usersonfiner.com/~user/
+
+or
+
+https://aggroup.com/finger/~user
+
+***** Reader
+
+Any person with
+
+a) access to a finger URL
+b) knowlege of a finger URL
+
+is able to read data on the finger - either manually or with the use or a Client
+
+***** Client
+
+Client MAY be any program which understands the <name> protocol, is able to make HTTP calls, and presents the data to Reader.
+
+
+
+***** Publishing on <name>
+
+To publish on the <finger>, user NEEDS to expose a
+
+1. single metadata file
+2. zero or more text files
+
+All of those files NEED be accessible via HTTP, HTTPS, or both.
+
+****** Metadata file
+
+Metadata file is used to advertise being a Publisher.
+It's a structured file (<format>), which exposed information needed for a Reader to follow a Publisher.
+
+The metadata file SHOULD be named ".fingrsoc.toml" (TBD), but user may decide on other name but it NEEDS to start with a dot "." and end with "toml".
+
+The metadata file MUST contain basic information
+
+- name if publisher
+- prefered form of contact
+
+The matadata file MAY contain references to any additional files:
+
+- the name
+- the full URL
+
+  Example:
+
+  #+begin_src toml 
+    [metadata]
+.... todo
+    [files]
+  #+end_src
+
+There should be reason for changing the Metadata file
+
+****** Text files
+
+The actual reader data is contained within text files.
+The text files are not a timeline, but rather a snapshot.
+Publishers are discoureged from creating archives but this is not forbidden.
+
+A publisher MUST publish at leat a ".plan" file.
+All files SHOULD be stored under the same path as the Metadata file, but any URL can be provided in the Metadata files list.
+
+A text file MUST BE
+- UTF-8 encoded
+- LR line breaked
+- realitively small (think kilobytes, not megabytes)
+
+each line of file MUST be max 80 characters in length.
+
+Note, that the files can contain graphical formatting (spaces, /, _).
+
+The files are plain text, so there is no way to attach multimedia, or any executable code.
+Note, that Publisher MAY attach URL of such.
+
+The ".plan" files SHOULD contain current information about the Publisher, but the exact content is up to the Publisher's will.
+Jokes, ASCII art, thoughts are highly encouraged.
+
+Note, that  ".plan" file MAY be present in the metadata file, but if it follows naming convetion (.plan file under the same root dir as the metadata file) it's not necessary.
+
+Publisher MAY publish any sensible (up to dozens) of other files, but each filename MUST start with a dot "." and not have any extension.
+Exact contents of such files is not normalyzed, and should be reflected in the "name" field of Metadata file.
+
+Each file SHOULD include creation and/or update date.
+
+***** Reading
+
+****** Advertising
+
+Publishers are encouraged to let others know about their Metadata file.
+The actual URL of the Metadata file is the only thing needed.
+
+The exact method of advertising is not defined, but it MUST point to the metadata URL.
+
+Publishers who own webpages, MAY add a custom meta tag:
+
+#+begin_src html
+<meta name="fingersoc" content="URL">
+#+end_src
+
+****** Clients
+
+A client MUST accept either
+
+a) the URL of metadata file
+b) the URL of any webpge. If the meta tag is present, the client MUST fetch and process it.
+
+Upon fetching of Metadata file, client MUST present the Reader with the name from the file.
+Only the .plan file MUST be fetched after the metadata.
+The content of .plan SHOULD be presented to Reader as representastion of a Publisher, so if the Client provides following multiple Publishers, upon selecting on of those, the .plan MUST be presented automatically.
+
+Client MAY auto-download fresh files.
+Note, that files SHOULD contain dates, the client is unable to determine if the file changed based on that information.
+Only change of the actual file (sha, contents...) MUST be treated as update of file.
+
+
diff --git a/content/projects/finger/_index.md b/content/projects/finger/_index.md
new file mode 100644
index 0000000..2ffee25
--- /dev/null
+++ b/content/projects/finger/_index.md
@@ -0,0 +1,212 @@
++++
+title = "Finger"
+author = ["User Mms"]
+date = 2024-11-13T00:10:00+01:00
+categories = ["projects"]
+draft = false
+weight = 2001
+abstract = "A different type of social network"
++++
+
+## Fingersoc {#fingersoc}
+
+----
+
+Status: DRAFT
+
+
+### Introduction {#introduction}
+
+&lt;name&gt; is a uni-directional, distributed, read-only social network.
+
+
+#### Name {#name}
+
+The inspiration comes from the `finger` protocol, where users of Unix systems could `finger(1)` other users to get some basic information aboout them.
+&lt;name&gt; tries to take that idea and allow it's usage in modern, interconnected internet.
+
+
+#### Requirement {#requirement}
+
+This memo follows the standard requirements of an RFC.
+To quite the RFC1288:
+
+> In this document, the words that are used to define the significance
+> of each particular requirement are capitalized.  These words are:
+>
+> -   "MUST"
+>
+>     This word or the adjective "REQUIRED" means that the item is an
+>     absolute requirement of the specification.
+>
+> -   "SHOULD"
+>
+>     This word or the adjective "RECOMMENDED" means that there may
+>     exist valid reasons in particular circumstances to ignore this
+>     item, but the full implications should be understood and the case
+>     carefully weighed before choosing a different course.
+>
+> -   "MAY"
+>
+>     This word or the adjective "OPTIONAL" means that this item is
+>     truly optional.  One vendor may choose to include the item because
+>     a particular marketplace requires it or because it enhances the
+>     product, for example; another vendor may omit the same item.
+>
+> An implementation is not compliant if it fails to satisfy one or more
+> of the MUST requirements.  An implementation that satisfies all the
+> MUST and all the SHOULD requirements is said to be "unconditionally
+> compliant"; one that satisfies all the MUST requirements but not all
+> the SHOULD requirements is said to be "conditionally compliant".
+
+
+### Use of &lt;name&gt; {#use-of-name}
+
+To use &lt;name&gt;, you need to understand three words:
+
+**Publisher** - he who publishes information on the &lt;name&gt;
+
+**Reader** - a human reading information published by a publisher.
+
+**Client** - a computer program for reading data on the &lt;name&gt; and presenting it to a reader.
+
+
+#### Publisher {#publisher}
+
+A published MAY be, either a human, or an automated process.
+Each published NEEDS to be able to publish files under URL accessible via HTTP(s).
+A publisher MAY be able to to it under any URL, be it either via manually updating files or with use of some automated process.
+
+A publisher SHOULD have a dedicated URL, like
+
+<https://useronfirr.com/>
+
+or
+
+<https://usersonfiner.com/~user/>
+
+or
+
+<https://aggroup.com/finger/~user>
+
+
+#### Reader {#reader}
+
+Any person with
+
+a) access to a finger URL
+b) knowlege of a finger URL
+
+is able to read data on the finger - either manually or with the use or a Client
+
+
+#### Client {#client}
+
+Client MAY be any program which understands the &lt;name&gt; protocol, is able to make HTTP calls, and presents the data to Reader.
+
+
+#### Publishing on &lt;name&gt; {#publishing-on-name}
+
+To publish on the &lt;finger&gt;, user NEEDS to expose a
+
+1.  single metadata file
+2.  zero or more text files
+
+All of those files NEED be accessible via HTTP, HTTPS, or both.
+
+<!--list-separator-->
+
+-  Metadata file
+
+    Metadata file is used to advertise being a Publisher.
+    It's a structured file (&lt;format&gt;), which exposed information needed for a Reader to follow a Publisher.
+
+    The metadata file SHOULD be named ".fingrsoc.toml" (TBD), but user may decide on other name but it NEEDS to start with a dot "." and end with "toml".
+
+    The metadata file MUST contain basic information
+
+    -   name if publisher
+    -   prefered form of contact
+
+    The matadata file MAY contain references to any additional files:
+
+    -   the name
+    -   the full URL
+
+        Example:
+        ```toml
+            [metadata]
+        .... todo
+            [files]
+        ```
+
+    There should be reason for changing the Metadata file
+
+<!--list-separator-->
+
+-  Text files
+
+    The actual reader data is contained within text files.
+    The text files are not a timeline, but rather a snapshot.
+    Publishers are discoureged from creating archives but this is not forbidden.
+
+    A publisher MUST publish at leat a ".plan" file.
+    All files SHOULD be stored under the same path as the Metadata file, but any URL can be provided in the Metadata files list.
+
+    A text file MUST BE
+
+    -   UTF-8 encoded
+    -   LR line breaked
+    -   realitively small (think kilobytes, not megabytes)
+
+    each line of file MUST be max 80 characters in length.
+
+    Note, that the files can contain graphical formatting (spaces, /, \_).
+
+    The files are plain text, so there is no way to attach multimedia, or any executable code.
+    Note, that Publisher MAY attach URL of such.
+
+    The ".plan" files SHOULD contain current information about the Publisher, but the exact content is up to the Publisher's will.
+    Jokes, ASCII art, thoughts are highly encouraged.
+
+    Note, that  ".plan" file MAY be present in the metadata file, but if it follows naming convetion (.plan file under the same root dir as the metadata file) it's not necessary.
+
+    Publisher MAY publish any sensible (up to dozens) of other files, but each filename MUST start with a dot "." and not have any extension.
+    Exact contents of such files is not normalyzed, and should be reflected in the "name" field of Metadata file.
+
+    Each file SHOULD include creation and/or update date.
+
+
+#### Reading {#reading}
+
+<!--list-separator-->
+
+-  Advertising
+
+    Publishers are encouraged to let others know about their Metadata file.
+    The actual URL of the Metadata file is the only thing needed.
+
+    The exact method of advertising is not defined, but it MUST point to the metadata URL.
+
+    Publishers who own webpages, MAY add a custom meta tag:
+
+    ```html
+    <meta name="fingersoc" content="URL">
+    ```
+
+<!--list-separator-->
+
+-  Clients
+
+    A client MUST accept either
+
+    a) the URL of metadata file
+    b) the URL of any webpge. If the meta tag is present, the client MUST fetch and process it.
+
+    Upon fetching of Metadata file, client MUST present the Reader with the name from the file.
+    Only the .plan file MUST be fetched after the metadata.
+    The content of .plan SHOULD be presented to Reader as representastion of a Publisher, so if the Client provides following multiple Publishers, upon selecting on of those, the .plan MUST be presented automatically.
+
+    Client MAY auto-download fresh files.
+    Note, that files SHOULD contain dates, the client is unable to determine if the file changed based on that information.
+    Only change of the actual file (sha, contents...) MUST be treated as update of file.