The wallet indicator in the nav bar should include some indicator of what network it is connected to.

We currently have used the words Post in some places and Article in other places. I think we need to clean this up to that it's consistent.

There are also some leftover (and unused) components and routes etc. (like the PostView) that should be removed.

An account/user should be able to post articles via an article/create action (https://github.com/gnosis/tabula#create-article).

This should be a "simple" HTML form, with no wysiwyg editor.

• Subgraph
• App

If a pinning service is configurated, upload the article content to IPFS and only include the hash in the article/create action's article property.

This will make publishing articles much cheaper for the user.

When no pinning service is configurated, it should function as it does today.

An account that has article/update permissions to a publication should be able to update (overwrite) properties of articles in that publication.

Can use the same form as when creating an article, just pre-populate it with the article to be updated.

• Subgraph
• App
• Design

Make it possible for an account to delete a standalone article posted by that account.

• Subgraph
• App

An account that has the publication/permissions permission should be able to give another account permissions to the publication via the publication/permissions action (https://github.com/gnosis/tabula#set-publication-permissions).

Display the same form as when creating an article, just pre-populate it with the article to be updated.

• Subgraph
• App
• Design

When connecting a wallet from a publication or article page and no pinning service is configured, the pinning service form does not show up.

We should add this via the implementation-agnostic API: https://ipfs.github.io/pinning-services-api-spec/.

The user should be able to:

1. Select a pinning service or provide an endpoint to a pinning service in adherence with the pinning-services-api-spec. For instance: https://api.pinata.cloud/psa.
2. The user should provide the accessToken/API key.
   3. Everything that's added to IPFS should be pinned using the pinning service (if the pinning service is not configurated, the user should get a warning or error that makes it hard to upload content without pinning it).

Both the selected service and the accessToken/API key should be saved in the user's browser storage (localStorage). This is configured on the browser level and used for all the user's interactions (any publication).

Tabula should also be usable without a pinning service:

• If a pinning service is configurated, images and the article text content should be uploaded to IPFS, and only a hash included in the transaction content.

• If a pinning service is not configurated, image uploads should be disabled with a warning (until #47) and article text content included directly in the article property of the article/create/article/update transaction (like it is today).

• Design

• App

• Design Modal
• Frontend

When you hit "Connect Wallet" and then select "Metamask" if metamask is connected to an unsupported network.
We should include a prompt to switch to a supported network, including a list of the supported networks.

The tabula logo should only be the favicon if the user is not in a publication view (IE: viewing posts, permissions, settings or an article)

TODO:

• After pressing the UI badge, redirect to the post view list

• Subgraph
• App
• Design

Tried creating a new mainnet publication, but it doesn't seem to have worked.

https://etherscan.io/tx/0x935bb1a1aaf1848542f5dc560cd47f2e986dde1881a9c7a7f8c73ce4a4054d94

After a transaction is submitted, there is no indication of if / how long it will take for the changes to be affected in the UI.

Related to #60

The publication ID is not in the URL when setting permissions. This is likely true for other routes as well. Wherever possible, we should make deeplinking possible by uniquely identifying the page int he URL.

On the subgraph, we can define multiple authors on one post. It would be really nice to expose this feature in the app. #83 is also related.

The "continue reading" button on the publication view is redundant and the copy is weird. Let's remove the button altogether.

The article preview image should be displayed in:

• the article list, and in
• the article page.

Use Medium as a reference for how to do this.

Instead of asking the user to change the network (chain), we can ask the wallet software to change the chain.

Separated from #56 into this issue.

Notes

• Sometimes, there is more than one "correct" network to change to.
• Only when connecting a wallet to an already open publication do we know what network should be connected to.

Implementation

• EIP-3326: wallet_switchEthereumChain
• EIP-3085: wallet_addEthereumChain

Tasks

• If there are multiple options: let the user select one of the supported networks. When one is selected/clicked, request the wallet software to change the network.
• If there is one correct network: request the wallet software to change that network.
• If the network (selected) is not added to the user's wallet software: request the wallet software to add the network, then request it to change to the new network (if it does not happen automatically).

Under the title on the article view, there is currently a link to back to the publication. This is redundant since there is also a link back to the publication above the title.

Presumably, this was meant to be a link to the author's profile, or something similar.

We should change this to list each of the author addresses/profiles.

We don't validate that the provided IPFS endpoint actually works until we try to use it.
In practice, this means that incorrectly entered details will cause pinning to fail after a transaction has already been sent.
To avoid this, we should:

• be explicit about which permissions are required if using Pinata.
• check the details on save and throw an error if they don't work.
• secret token should be a password input, so that it is not cached by the browser.

Accounts with the article/delete permission to a publication should be able to delete articles in that publication.

• Subgraph
• App
• Design

Make it possible for a user to browse a publication.

Should include the publication info and the articles posted to the publication.

• App
• Design

It should be possible to get directly to a publication via a URL. Something like: /publication/{publicationId}. This should not require or "push" a reader to connect a wallet. Should be browsable for "web2 users".

An account with the publication/update permission to a publication, should be able to update/overwrite the publication's properties.

Can use the same form as when creating a publication, just pre-populate it with the publication to be updated.

• Subgraph
• App
• Design

Transaction is being verified.
View on Etherscan. (with link)

Once you start editing an article, it's not immediately obvious that you can cancel the action by navigating away. We should explicitly provide a cancel or back button.

Currently, the publications/publish route only lists publications on the network that the wallet is connected to. It should list publications in which the wallet has permissions on every network, regardless of the network the wallet is connected to.

Don't show an error when uploading to IPFS a file that is already pinned.

Instead, we can show an info notification saying The file {fileName} is already pinned.

This is what shows up on my local env:

And on the figma:

Mentioned here: https://discord.com/channels/@me/930504209403633704/971103584332709939

When you update the permissions, the indexing (info) and success message both show at the same time, on success. The details link only shows on the success notice, but it's ideal to show this on the indexing status toast message.

It would be really great to have an author/user view which exposes the author/user's interactions; what publications they contribute to, the posts they have authored, etc.

Related to #83 and #84.

Toast notifications should be automatically cleared after a short delay, say 5 seconds.

Make the subgraph deployable to any network where Poster is available.

• Convert to The Graph Hosted Service
• Create deployment scripts

If a pinning service is not configured, convert images to BASE64 encoded image string for all image uploads, and use that instead of the IPFS hash.

We will probably need some way of downgrading the image before converting it so that it can be posted to the blockchain.

Have the chain id as part of the publication id. So that the frontend can use that to select the correct subgraph and chain when a user connects a wallet (from within a publication or article).

• app
• subgraph

We should check if there is a local provider available, if not, we can check if Infura is accessible, if not, we spin up a js-ipfs node.

Check this link for hardcoded ipfs.infura.io URLs: https://github.com/gnosis/tabula/search?q=%22ipfs.infura.io%22

We do not want Tablua to be easy to censor ;)

It should be possible to get directly to an article via a URL. Something like /publication/{publicationId}/article/{articleId}. This should not require or "push" a reader to connect a wallet. Should be browsable for "web2 users".

For instance, make blog.gnosis.com "point to" the Gnosis Tabula publication.

Proposed solution

1. Make a CNAME record for blog.gnosis.com, pointing to the tabula domain (domain where the app is hosted).
2. When the Tabula app loads, it should check the current href (current URL).
3. If the current URL is not the Tabula app URL, we request a TXT record from the domain using DNS over HTTPS, here is for instance, the solution from CloudFlare The TXT record returns the publication id for the publication to display (we can make the publication ID start with the chain ID).

What a user will need to do to set this up

1. Set a CNAME record pointing to the Tabula App.
2. Set a TXT record with a publication ID.

Pros

1. Relatively easy for a user to set up.
2. DNS over HTTPS can increase user privacy and security by preventing eavesdropping and manipulation of DNS data (ref: https://en.wikipedia.org/wiki/DNS_over_HTTPS).
3. No server needed (for us to run).

Cons

1. The lookup relies on a DNS over HTTPS provider.

Should display the relevant properties (created at, last update, authors, etc.) from the article in addition to the actual article.

• Design
• App

An account should be able to create a publication via a publication/create action.

The account that creates the publication should get all permissions for the publication on creation (can be changed later).

• Subgraph
• App
• Design

An account/user should be able to delete an article via an article/delete action. If the account is the publisher of the article and it's not part of a publication.

• Subgraph
• App

• REACT_APP_API_URL needs to be removed from packages/app/.env.example.
• The client (that uses REACT_APP_API_URL) should be removed: packages/app/src/services/graphql.ts.
• All dependencies on that client need to be removed and converted to the new subgraph using BASE_SUBGRAPH_URL.

If a user has not configured a pinning service, we should display a warning something like:
"Here is the hash of the image you uploaded, since you have not configured a pinning service you need to pin this hash yourself in order for the image to load for other users." and display the hash.

The easiest is probably a modal, @cedricwaxwing?

The blocky in the nav bar does not match the address (appears to be using the checksumed address as input, rather than lowercase).

• When going directly to an article in a publication that I have not visited before the publication header is not loaded. Can be reproduced by opening an article directly in an incognito window.
• Also, can we make the URL like this:

/#/publication/{publicationId}/article/{articleId}

• Reloading the page when visiting an article brings the user to the Tablua landing page. It should instead keep the user on the article.

The metatags and favicon on the app are still the default from the create react app template.
We should update the:

• tabula favicon
• metatags on the home page
  • og:title "Tabula"
  • og:site_name "Tabula"
  • og:description "Instant web3 publications for writers, DAOs, and any Ethereum-based account."
  • og:type website
  • og:url https://tabula.gg
  • og:image full URL to a preview image
• metatags on a publication page
  • og:title "{Publication Name}"
  • og:site_name "Tabula"
  • og:description "{Publication Description}"
  • og:type website
  • og:url https://tabula.gg/{publication Id}
  • og:image full URL to publication preview image
• metatags on an article page
  • og:title "{Article Title}"
  • og:site_name "{Publication Name}"
  • og:description "{Article Description}"
  • og:type website
  • og:url https://tabula.gg/{publication Id}-{article id}
  • og:image full URL to article preview image