# Our company

## The problem

Allow

## Purpose (why we exist)
To help writers to publish their written content easily, accessible to everyone, while being able to make a living of it.
To provide readers with quality content, without having to be tracked/sold to any advertiser.

## Vision (what we're working toward, were you want to be)
A world where content is available freely, with respect to humans while allowing content creator to make a living out of it

## The solution

### Réu 17 novembre 2020

Assurer la pérennité de nos écrits.
On s'adresse à des écrivains.
Donner accès aux écrits après la mort.

Propriétaire de son contenu ?

Pourquoi est-ce que les personnes changent de plateforme de blogging. Hypothèse : t'es emmerdé par la plateforme. Car à maintenir, l'herbe est toujours plus verte à côté.

Plus value : no brainer / opiniated. Get out of the way of the writer. Distraction free
=> + publication

Point centralisé de publication / Marketplace de publication
Brave quand on lit, attention token? Flattr?

Idéal : tu crées tout rien qu'avec la force de tes écrits. La diffusion se fait à la force de l'écrit, tout comme la rémunération.

Pas de likes, pas de métriques parasites, pas de statistiques

Blot.im => pusher sur git ou répertoire dropbox

Les gens savent utiliser git / éditeur de texte

Future proof, trouver un moyen de l'être

Connecté aux sites de news? Journalistes qui viennent chercher vos contenus

On enlève le problème de publication aux auteurs. Vous écrivez et on s'occupe du reste.

Une plateforme pour vos écrits.

## For next week

# Brainstorming

## Vince

Focus on writing, focus on reading: respect people's time, people's privacy, and people's planet when publishing content

## Ploum

Focus on your writing, not on your image. Be read, not liked or clicked.

## Workflow

1. Write MD files with some metadata (slug,publication date,drafts,others?)
2. Each metada has a good default
3. Command line to sync with the server (git by default)
> Vince: I think we should provide our own "abstraction" to git at the end. But ok to start with git.
4. Pictures are automatically optimised.
5. No online interface at all.
> Vince: Yes, except for us maybe?

6. No statistics at all.
> Vince: We may even remove HTTP server logs? But if so, we should check if we're ok with the law of the country in which we will host the pages

> Vince: Agree, we need to decouple all the things. A command line to publish and that's all. We need to have the freedom to change all the things in between.

## Pages

1. A complete post. (some informations should be added on every page, how to configure it?)
> Vince: what information are you talking about?
2. A homepage (what should be on it ?)
> Vince: let's start with the blog post list?
3. A static page to give information about the blog. Or multiple static pages through the metadata ?
> Vince: As you can add a new page by creating a new markdown post, why not allowing to create a new page by just creating a new markdown file? I mean static pages or blog post pages are juste pages… generated from metada, no?
4. A list of post (browsable ? Searchable ?)
> Vince: The home page at first? It could be searchable by an external tool like duck duck go or an external search engine that respect privacy? (just opening duck duck go when submitting the search request)

## Series

Inspirations : Printeurs

Some posts should be part of a "serie". It means:
- When reading a post from a serie, you can easily go to the previous/next one.
- You can export the whole series (epub/pdf/…) in chronological order
- You can subscribe only to the series.

Series == tags ?

> Vince: I think that tags are enough for a minimalist approach

## search

Should we offer search ?

> Vince: I don't think so. We should rely on duck duck go or an external tool. Our own "search in readable websites" search engine as another side project?

## Hosting

Hosted on raspberry pi like server?

# Read.as, the feedless and distractionless social network

Social networks today are all about getting your eyeballs glued on the screen, to spy you and to make you see targetted advertising. But can we imagine a new kind of network? A network where the main objective is to bring value to the people using it.

This is why read.as focus on one particular thing: making you read what you really want to read, making you discover what your friends think you should discover but not burrying you in suggestions by anonymous algorithm.

## Design

Design should be e-ink first, without any scrolling and all in black & white. Mobile app and web app are the same, to convey the idea of calm reading/no scrolling, no distraction.

An important point of design is that you always find the app at the same place than when you left. The "homepage" is only for the first launch. If you log on any device, you can immediately continue reading from where you were. Changing context is a decision you take.

Read.as has only 3 differents screens. Each screen has a very specific goal:

### Screen 1 : Reading
The goal of this screen is, of course, to read the content. But that screen should also inform the user why he's reading that, what is the context and allow the user to share the text or recommend it.
By default, only the text is shown but there are 3 bouttons that appear if clicking on the top/bottom middle (Kobo style ?).
-> Button 1 is to go back to the library
-> Button 2 is to open reading settings (fonts, etc)
-> Button 3 display the context menu.

The context menu displays, in that order :
- Date to which the read was added to the library
- If the current read is part of a serie the user is currently reading
- Other users that have recommanded that read personally to the current user (with date and optional comment)
- Other users that have recommanded that read publicaly and that current user is following
- If the current read is from a RSS the user is subscribed to.
- A button to recommend the read. This recommendation can be either public or private (in which case a valid recipient has to be entered). A comment can be added to the recommandation.

## Screen 2 : Library
Library is something that can be a great deal to design. In a first iteration, a propose to have a simple list of contents with only the following filters: "finished", "currently reading" and "unread".

Each item has the following properties:
- Title

- Author

- Episode X of series ZZ (optional)

- Date added

- date started

- date finished

- percent read

Unread : date started == None (percent read is, by definiton, at 0%)

Currently reading : date started != None && Date finished == None

Finished : Date finished != None (percent read is usually 100% but a reader may mark as read without finishing the thing)

The center place is the “Currently reading”. When searching, results from your library and finished are displayed.

If the “currently reading is empty”, the library is displayed. If the library is empty, the “add content” is automatically displayed.

### Screen 3 : adding new stuff

Purpose of the screen is to add content to the library. You have "one time add" and "subscriptions".

- One time add : epub or link to an article (Pocket style)

- Subscription : public recommandations from another read.as user, RSS

It has to be noted that Series don't appear on this screen. Series are contents magically linked together. When you finish an episode of a serie, Read.as will ask you if you wat to read the next episode, even if this episode is not in your library already. In facts, episodes you should not read (because you have to read others first) are hidden from your library, even if they are added by other means (if you add it manually, it will ask you if you want to skip previous episodes).

## The inbox

There's no such thing as a feed in read.as. Feed are a way to hook you but they distract you from what you really want to do. They give you dopamine rush for little real intellectual value.

This is why the center place of Read.as is an inbox of what you want to read. There are multiple way to add something to read in your inbox :

- By sending a link to Read.as (Pocket style).
- By uploading an epub to read.as. The whole book is then in your inbox and can be read through the app or through read.as compatible ebook readers.

When you add a content to read.as, you can optionnaly add a comment on why you want to read that particular content. This might be helpful when you stumble accross that content months later and are wondering if it still worth the read or not.

## Series

Often, we want to read a serie of content in a particular order. They can be books, they can be a serie of articles. Read.as implement the concept of series. The serie concept might be directly from the source (such as Write.as or the Wordpress Series plugin) but you can manually create an ordered serie.

The particularity of series is that only the next episode is displayed in your reading list. When you finish reading it, read.as will ask if you want to continue this serie. If yes, the next episode is added to your reading list. This could be done even if the next episode is not yet published. It means it would get added to your reading list once it appears.

There could also be series of series. When you finish a book, the next one is recommended to you.

## Subscriptions

Another way to populate your inbox is to subscribe to write.as authors and to RSS feeds. To keep your inbox sane, subscription are considered as series so you only see the next article. The fact that you are not informed directly if a new post is published is considered as a feature.

A blog may publish some series. In that case, the series is displayed next to the "normal" feed. This means that people can follow a blog routine posts while also following series published on the blog but each at their own rythm. Also a reader may stop reading a particular serie, in which case posts from that serie will be hidden but the rest of the blog will still be displayed.

One can also subscribe to any ActivityPub actor. For each new ActivityPub object, the following happen:
if object == Article : add object to library
elif object == message && message contains URL : add URL to library
else do nothing

## Recommandations

But all of that can be considered as Pocket on steroid without any social part. How can we make read.as more social? By allowing you to make and receive recommandations. You can send recommandations to a particular Read.as user. The content will be added in his inbox. In that particular case, the comment about why the content is added is mandatory. To prevent spam, one could always block "future recommandations from that particular user" (if the spam become a problem, a whitelist might be an idea).

Every read.as user could also make "public recommandations". Your public recommandations are automatically added to the inbox of your "read.as subscribers". But subscribing is anonymous : you don't know who and how much subscribers you have. Public recommandations are also posted on Mastodon.

Recommandation is an ActivityPub message with a link to the content (and, optionnaly, a comment in the message). The message is either public or private.

Recommandations can be about a particular content or about a whole serie. It is then possible to upload the 5 H2G2 books or the 32 discworld novels as one serie that you recommend to someone or publicaly.

## Duplicates

If a given content is duplicated, this only means that they are multiple "to read comments". You can open an item and find that "You've added that content from Firefox on August 9th, Jane recommended it you on September 18th because "I thought of you while reading this" and it's chapter 27th in the series you are currently following".

Instead of becoming a huge mess, your inbox tend to stay calm.

##Notifications

Unlike most systems, there's no notifaction at all. In case a urgent action is required, a mail is sent. Else, we consider that it is not urgent. If items are added to your "inbox", you will find it sooner or later when exploring it. If the inbox is filled, we don't believe a notification will help you.

## Annotations (no clear right now)

Another interesting features is the fact that you can highlight and comment some part of a content. If you share that highligh/annotation, the recipient will see your annotation while reading the content.

## Micropayment

But how to pay for all of that? The idea is quite simple: while reading a serie, if you want to automatically get the next episode, you need to send a microdonation to the author. There's no enforcement as the content is public and it is quite easy to add manually contents to read.as. But when reading a book, a blog or any kind of series, if you want to see the next episode, it make sense to send a few cents to the author. A fraction of that goes to the read.as instance.

If the content has been recommanded to you by someone, a fraction goes to that person. And if it was recommended to that person, a fraction of that fraction until the source is reached. This means that sharing good content that people appreciate and will share themselves is encouraged.

If the author is unknown, the money is held until it is claimed. If the author is dead or if he has clearly stated he doesn't want that money, the money is donated (for example to the Gutenberg project ?). It should be noted that the money is not about paying for copyrighted materials. Readers are supposed to follow the law of their country and share publicaly contents which can be shared. Private share, on the other hand, is never monitored (so if someone write a bot that share privately with you every book from libgen.io, there's nothing we can do). Money here is only a donation to the author and the sharer. That money doesn't imply that the content is bought (as far as we can "buy" contents).

Idea : what if the money earned was displayed transparently? Just to break the taboo about money and realise authors don't earn lot of money. Downside: this is a clear "success" metric that will generate lists of "the best paying reads" etc.