Next steps on Clickbait Buster

[joaosantos15]

Issue by joaosantos15
Monday Oct 30, 2017 at 17:00 GMT
Originally opened as inesc-id/dclaims-pm#22

---

[joaosantos15]

Comment by joaosantos15
Monday Oct 30, 2017 at 18:18 GMT

---

As discussed on this week's meeting, there are some open questions as to the next steps of development of this application(clickbait buster).

The hot topics are

1. How to identify articles
2. What should be the next steps of development.

1. How to identify articles?

In this first version, news articles are identified by the webpage's http link they are in, for instance Ryanair's example article's ID is turbina.gsd.inesc-id.pt:8095/post.html. This is not an ideal situation because the article can be easily moved, resulting in a different link.

A first approach would be to use a hash of the concatenation of the article's title and content. We would start by putting the article in a canonical form (removing spaces, html tags, etc). This is one of this week's goal

2. Next development steps

The idea is to determine this week's goals, and add them to the timeline.
@nuno-santos and I talked about different areas we could focus on, these were our conclusions about each one of them. @diasdavid we'd appreciate your input, as you may have some better insight in some of them.

1. Use a hashtree to track articles.

   • This would allow to track article changes throughout time. For instance, we could use the hashtree to track articles on several levels (words, sentences, paragraphs) and if any part of the article was changes it would be easy to tell which part, without requiring to save a copy of the article
   • This would also enable to quote articles. The goal of this application is to allow Verifiers to quote parts of the news article's body that disprove the title, therefore it makes sense to have a way of checking that verifiers' inputs belong to the news article.

2. Focus on Claims' schema

   • Work on the data type to be used. @Dias-David suggested that claims could have different degrees of strength depending on the claim it made (totally wrong,inaccurate, correct)
   • We could then start working on how these could be issued and revoked

3. Work on identifying/authenticating the Verifiers

   • From what @nuno-santos and I talked about, this seems to be something we should not focus on yet, but @diasdavid, you might have a different opinion. This would result in having a way to sign the verifiable claims, it would probably use DID's as well.

4. Start decentralizing the system

   • Start taking the required steps to move towards a decentralized/trustless architecture. This could start by:
     • Moving the storage to IPFS
     • Discussing how to best use a blockchain here

5. Desirable application features

   • @nuno-santos mentioned a few features that would be cool to have on the application, such as a filter to only show claims from peers the user trusts, have some digest display of how many claims argue the title is good vs how many argue the opposite.
   • We both agreed that these features should only be implemented once the system is moved towards a decentralized architecture

Once the discussion on the next steps is over, I'll update the timeline.

[joaosantos15]

After email discussions, the goal for this week is to make the plugin interact with the website, rather than be embedded into it. Being tracked in #3