• split PostList and Post
• show date
• show OP
• show button bar to open comments etc

This is one of the biggest problems in successfully implementing this protocol.

It needs an efficient algorithm that tries to keep the most relevant data, throws away the less relevant, all while trying not to luck up the user's web browser and being reasonably fast.

It would be the coolest thing if the app could load in the background while the user looks at the landing page.

Accomplished using webpack's code splitting

Hey @fazo96 this is very cool.

What do you need for this to work on the gateway? is it only writing objects and IPNS names?

Currently, some things are outsourced, they should be internally served:

• The Raleway font files are fetched from google

The API is becoming a huge spaghetti code mess 👎 it needs to stop

• use skeleton to style application
• use React for functionality
• use Browserify to recycle npm modules and server code
• create a build system (probably based on gulp) to build, browserify, minify the app and ship it on ipfs

• have the API emit error events when something goes wrong
• have the web app show error notifications when something goes wrong

• use classes for react components
• use ES6 import instead of require
• use function name(){} instead of name: function(){} when applicable
• use react stateless components when applicable
• use promises instead of horrible callbacks (solves callback hell)
• investigate using generators or async/await

An indicator that counts how many nodes have some hash

• get an IPFS mock
• get disposable IPFS nodes
• pin a profile to disposable node then start testing on it
• set up testing framework
• test every API endpoint

Throroughly testing the API will be very hard because for example when looking for posts, it could take a long while before they are all found and often there is no end to a query

Needs #20

Requires moving to IPFS 0.4 #20

• profile creation and editing
• board creation and editing
• writing posts
• editing posts
• deleting posts
• writing comments
• editing comments
• deleting comments

PinCoop is a service that allows users and machines to pin stuff to a collection of nodes, to help having data always available

PinCoop or similar should be used to ensure a profile is always available on ipfs-boards.

Needs:

• ability to recursively pin ipns ids
• probably go-ipfs 0.4

If illegal content gets published we need a way to stop mainstream users to see it even if they open the link.

A good solution would be global blacklists that a user could use, and one/some of them active by default.

EDIT: I think IPFS also has his own solution, in that case we would just need to build something to signal the blacklist's authors that some content may deserve its place in the blacklist

• download posts from admin
• approval list: download posts from approved list
• whitelist: download posts from whitelisted users
• whitelist: download comments from whitelisted users
• blacklist: download posts from random users and apply blacklist
• user interface to handle all these

Other stuff:

• inject op fields into posts when it's obvious
• inject op field into posts when using whitelist or downloading from random people
• Important for security: when the op field is already in the post, figure out if that guy really has the post by using ipfs.ls on his /posts/boardname. In other words, verify that the guy actually posted the thing before putting it on the screen. Being worked on in #77
• figure out how to merge into the same post when multiple people post the same thing

// When a component inside the component being rendered by the router also needs
// access to the boards api, it appears unitialized and never initializes to it
// for no apparent reason. Calling init twice (one automgically and one
// when the root component mounts) works as a cheap, horrible workaround

Possible fixes:

• use react props to pass down access to the api and solve #52

For example:

• configuring the API port

Should probably use this

davidar's fork of markup.rocks was built to work on IPFS. Should consider using that

The idea is:

• Loading page while the app hasn't loaded yet
• Landing Page #32
• Error page if can't connect to IPFS
• @user
  • board
    • specific post referenced by IPFS hash that shows comments
      • specific comment referenced by IPFS hash that shows subcomments
• users, which is the users page
• me, which redirects to the current user's profile
• board (without specifying the user, works like user/board)

The problems:

• URLs are already long... a nice way to shorten them would be good. Too bad there's no easy way

• use localStorage when available (in the browser)
• use a file somewhere when localStorage is not available but the filesystem is
• don't use this on IPFS 0.4 or newer

POST plans to resolve the problem of interoperability between applications: using POST as a protocol for IPFS Boards would allow:

• Interoperability with other Applications using POST
• Having a well documented protocol as a base, thus better organization and clarity
• Easily extend the application using POST extensions

Roadmap:

• Take out protocol from this repo
• Create one or more POST extensions that provide the required functionality for ipfs-boards, possibily:
  • POST-discussion-board
  • POST-comment, POST-user-profile (if core is not enough)
  • an extensions that defines a blog-style post (with title, body, author, date, media attachments)
• Update the API to comply with the new protocol

Blocked by:

• Need First draft of core spec of POST

• make it possible to ignore files bigger than kilobytes
• automatically ignore metadata (like json documents) files when they're too big to be legit
• create interface to inform user that data wasn't downloaded because too big

• tool to create a sample profile
• tool to publish profile
• tool to serve the webapp
• tool to ship the webapp over IPFS
• tool to quickly set CORS on go-ipfs

• finish the data storage specification
  • move everything in a subfolder of the root folder of the IPNS publication
• move FAQs in FAQ.md
• move technical stuff in HACKING.md
• leave only basic informations on the project and its current status in README.md

• drop browserify, use webpack
• modularize the app
• set up build system on par with what we have now with browserify and gulp
• use code splitting to reduce initial download size for the app

I decided to do this now because:

• The app is getting way too big
• The compile times with browserify are getting way too long (two minutes sometimes) and webpack takes at most 15 seconds
• We will eventually need the cool webpack features (Code Splitting)

Webpack stuff already merged, need to modularize the app though

It's also kinda related to #19

Requires #64

• implement IPFS version checking
• drop IPNS caching layer if performance without it is ok
• use updated js-ipfs-api with files API (currently using not-yet-released versions of js-ipfs-api)
• drop support for 0.3 (probably not gonna do this until 0.4 is out)

added to other cumulative issue for protocol updates

Just like anonymous-networks, we need a better name!

• Nettangle, Rektangle, Tanglepond
• Impakt, Impacket, Impackt ? Impakt sounds nice
• Citadel ?
• uboard or ubrd
• roundspace
• IPSN: InterPlanetary Social Network
• meshden, Meshub
• IPFS Hub or IPHub as in InterPlanetary Hub
• BitPod, MeshPod
• Graphy
• Merklehub
• graphhub (hh) (thanks @dignifiedquire 👍 )
• hubwired, wirehub
• Hubroid, Hubrid
• Fluxeen
• FluxHub (xHub) (thanks @dignifiedquire again 👍 )
• Flaxen, Linseed, Leanseed
• Fluxseed (@dignifiedquire again 👍 )
• Seedly, Seedflux, Seedflow
• Flowy, Flowery
• Rokkit
• Hinn, Hyn, Hynn
• Pinnit
• Filer, Fileform

Discuss and write down specifics for these features:

• ability to share pages written in markdown, which support versioning and are listable from the user's profile #81
• embed a default board (like "blog") in a user's profile
• trusted profiles list: your trusted profiles' trusted profiles are also marked as trusted
• ability to have URLs pointing to IPFS hashes: the app figures out what that hash is and it shows content appropriately (a post, a comment, a board, a profile, media files)
• global search engine for content (finds users, boards, posts, comments, hashtags, etc based on query)
• hashtags for posts
• chat system, would enable:
  • chatrooms (boards with a chat and no posts)
  • chat + boards (regular boards with a chat)
  • chat should be configurable like boards
  • should use a chain system where every chat message has a link to the previous one and only the latest is exposed
• Access profile from multiple devices
  • best idea is probably have password protected keys and ability to import/export them
  • see #76
• Outsource administration of boards
• Multimedia
  • images
  • videos
  • audio
  • files and folders
• nested boards, like a forum
• sticky posts
• maybe comment with the board/blog as a parent instead of a post
• password encrypted content
  • see how Laverna does it
• Ability to verify profile with social media, keybase (like keybase)
  • see #76
• hidden content (requires IPFS to support it)
• code repository hosting, requires:
  • js implementation of git
  • other github-like features
• content versioning: app and protocol should be aware of previous versions of content

• How does it work page
• FAQ page
  • add answer about localstorage security: ipfs gateway uses suborigins so if browser supports suborigins then it's safe

by separating them into sublists ordered by date.

Also see #44 first

• top level comments to posts
• comments to comments
• open/close thread interface
• comment count displays even without opening threads and without downloading the comments handled in #69
• basic comment CSS
• cool comment CSS to display subcomments slightly shifted to the right
• comment permalink, works like post permalink, makes it easier to navigate threads on mobile

It can be reproduced by visiting the users page, seeing hundreds of requests of IPNS resolution start instantly, then going to your own profile and seeing that it doesn't load even though it should do it instantly. That's probably because the event emitter exploded.

searchUsers is essential, so it needs to be rewritten in a way that doesn't lock up everything. For example, sequentially figure out each one of the users.

Possible solutions:

• use async library with ForEachSeries to rewrite it

This page has:

• a list of users that have been discovered
• a search box to find people