+++
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}

<name> 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.
<name> 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 <name> {#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 {#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.