1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
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}
<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 <name> protocol, is able to make HTTP calls, and presents the data to Reader.
#### Publishing on <name> {#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.
<!--list-separator-->
- 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:
```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.txt" 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 have a ".txt".
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.
|
