diff options
Diffstat (limited to 'content-org/finger.org')
| -rw-r--r-- | content-org/finger.org | 210 |
1 files changed, 210 insertions, 0 deletions
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. + + |