tbl_price
Description: Caches current prices for the desired cryptocurrency. This saves API calls.

-- auto-generated definition
create table tbl_price
(
fld_price_id serial not null
constraint tbl_price_pk
primary key,
fld_price_sym1 varchar(20) not null,
fld_price_sym2 varchar(20) not null,
fld_price_value double precision not null,
fld_price_update timestamp
);

alter table tbl_price
owner to postgres;

tbl_nodes
Description: Allows the storing of node information to which the application can talk to. In the column fld_active you can store if the node should be used. One can define multiple nodes and we will provide an interface to change them.

-- auto-generated definition
create table tbl_nodes
(
fld_node_id serial not null
constraint tbl_nodes_pk
primary key,
fld_node_tls text,
fld_node_macaroon text,
fld_node_ip varchar(255),
fld_active boolean default false
);

alter table tbl_nodes
owner to postgres;

The background image of an article is defined by its assigned category. Each category has one representative image defined by the admins.

Background images should be placed in source/view/assets/img/

@RomanBoegli

The discussion arose wether to track the history of an article or not (e.g. WordPress). To accomlish this, we could implement a 1:N relation from tbl_Content to itself. The current primary key fld_cont_id will then always represent the "parent" or the "ancestor". When a new version of an article gets initialized, the ID of the parent-article will be held in a new field called fld_cont_parentid.

Each article must be assigned with a category. Hence, the draft view must provide an appropriate control.

This issue should track our advancements on the ERD and class diagram.

recycled from issue 10

I'd say we stick with your initial suggestion of providing a view where categories are shown in tiles. Once a user clicks on a tile, we show the appropriate articles, ascending sorted by publishing time.
A full search field should definitely be placed into the header. The given inputs could be passed through a sequence of "search locations". Let's say a user types in «bitcoin» then we first look for articles that share great similarity in their title. Secondly, we check, if the search term corresponds to an category. Thirdly, we look for articles that include the search term most often in their body.
As an enhancement, we could come up with a more sophisticated search algorithm (such as BM25 for which even a PHP implementation exists)

What should be included:

• architecture (including important concepts such as domain model, router, etc.)
• external services used
• domain model (class diagram / ERD)
• specialities
• design decisions
• short scenario description (what is this application used for)
• implemented use cases (favourable documented in use case diagrams with 1-2 sentences of explanations)

It does not have to be in the same extend as the reference project. AD likes diagrams!
Code documentation would be nice, but it's not expected that all the functions are documented within PHP comments.

recycled from issue #10

Let's force users to assign an article to one category out of a set of categories that we (admins) have predefined. Nonetheless, authors should still be able to tag their articles by 3 to 5 self-defined keywords. Consequently, this implies: {tbl_content[n]:[1]tbl_category} and {tbl_content[1]:[n]tbl_keyword}.
Small disadvantage: assigned category and keywords could contradict (weird author anyways)
Big advantages: easy to implement and great basis for building a search by category _view.

I think tbl_content <> tbl_keyword should also be a N:N relation so you can still filter by keyword and find many related articles.

update: Keywords are assigned under the relation {tbl_content[n]:[n]tbl_keyword}

General (MVP)

A list of all transactions (payments/withdrawals) associated with a specific user account.

PDF export

We could additionally allow the user to create a PDF report of a given period (last month / last year / all). This would be an additional (optional) feature.

Background

We should allow the management of the full node as well as other system-wide parameters (maybe fee policy, management of user accounts, definition of categories) by administrators.

Requirements

Role model on users (not every user is the same). I could think of either an admin flat (true|false) or an additional role entity that can be set on the tbl_user.

Possible Features

Node Mgmt

Manage not only one node but multiple and decide which one is active.

Create new categories dynamically.

Block users from accessing their profile.

Use LNURL for withdrawing funds via QR codes:
https://github.com/btcontract/lnurl-rfc/blob/master/spec.md

Registering

• check for existing usernames / email addresses
• check password (long enough / special chars / repeated)

Profile

• only changes that are allowed

https://github.com/sparksuite/simplemde-markdown-editor

Every time an article is visited the view should be logged so to show the author a statistics of how much his content is being viewed.

To consider

• Do we count all requests
• or only once per IP / user in a specific time range

Since we implemented a markdown editor, I suggest to distance ourselves from allowing file uploads. Thus, we could delete tbl_Attachment.

Do you consent?

@RomanBoegli @TKone7

Background

It should generally be possible to use the platform without any authentication. Paying and reading articles can be realized by local client cookies. If they are gone, of course, the user has to pay again to read. When it comes to receiving money (on our infrastructure of the author's behalf) we should know how to contact the author.

Proposal: 3-tier approach

Unregistered

• no registration needed
• can read free articles
• can pay for articles (as long as cookies are intact)
• can donate to authors

Registered (unverified)

• registration with username and password (still anonymous, since username can be anything)
• (can do all the above)
• paid articles are linked to user account (instead of cookies)
• can see (and export) transaction history
• change his profile

Verified

• need to indicate valid e-mail (either at registration or whenever want to switch to this state)
• needs to verify e-mail with a link sent to it
• (can do all the above)
• can write articles
• can receive payments
• can receive donations

Implementation

It must be ensured that switching between the tiers is possible. Especially between unverified and verified users we need to do additional checks.

• Require user to verify before writing
• only allow donations to verified users
• E-mail address cannot be removed when articles are online or any balance is present
• changing e-mail address triggers re-verification, if unsuccessful, the old state should be preserved

At the moment we have simple session-based authentication.

Token based

In stage 12 of the reference project, token-based securing is introduced which should be adapted to our project.

• implement token based authentication

Password reset

Stage 13

• implement password reset

To each article, one category has to be assigned. The set of possible categories is given by the adminitrators.

It would be nice, if the user could self-define how much gets previewed of published non-free article.

A rather simple solution would be to implement an additional field indicating the number of previewable charaters (not so intuitive though):

A more user-friendly solution would be a delimiter mark to be inserted in the markdown editor.

New table

tbl_auth_token

-- auto-generated definition
-- fld_user_id is a fk to the tbl_user (fld_user_id)
create table tbl_auth_token
(
    fld_auth_id         serial       not null
        constraint tbl_auth_token_pk
            primary key,
    fld_user_id         integer
        constraint tbl_auth_token_tbl_user_fld_user_id_fk
            references tbl_user,
    fld_auth_selector   varchar(255) not null,
    fld_auth_validator  varchar(255) not null,
    fld_auth_expiration varchar(255) not null,
    fld_auth_type       integer      not null
);

alter table tbl_auth_token
    owner to postgres;

altered table

tbl_invoice

added columns

-- fld_auth_id is a foreign key to tbl_auth_token (fld_auth_id)
fld_invc_lnurl_challenge varchar(510),
fld_invc_lnurl_secret    varchar(510),
fld_auth_id              integer
    constraint tbl_invoice_tbl_auth_token_fld_auth_id_fk
        references tbl_auth_token

create unique index tbl_invoice_fld_invc_lnurl_challenge_uindex
    on tbl_invoice (fld_invc_lnurl_challenge);

create unique index tbl_invoice_fld_invc_lnurl_key_uindex
    on tbl_invoice (fld_invc_lnurl_secret);

Come up with an idea how the posts can be tagged or assigned to categories.

User-defined vs. static categorization

This will be the main decision point. Should the user be forced to use existing categorizations or is he able to self define them? Advantages and disadvantages?

1:N vs N:N

Is an article in exactly one category or can be assigned to multiple 'topics'?

How do users find articles?

Will there be a simple category list to browse through or do we supply a full search?

Because the program crashes when the invoice gets a little too long.