New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`network.informo.article` matrix event #9

Merged
merged 5 commits into from Nov 21, 2018

Conversation

Projects
None yet
2 participants
@GordonF42
Copy link
Member

GordonF42 commented Nov 7, 2018

This defines the content of an Informo article event

Currently this implies having two "formats" for network.informo.article events

  • Signed article:
{
    "content": {
        "algorithm": "ed25519"
        "sender_key": "IlRMeOPX2e0MurIyfWEucYBRVOEEUMrOHqn/8mLqMjA"
        "signature": "0a1df56f1c3ab5b1"
        "signed": {
            "title": "Lorem ipsum",
            "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit."
        }
    }
}
  • Unsigned article:
{
    "content": {
        "title": "Lorem ipsum",
        "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit."
    }
}

To know if an article event is signed or not, the clients will need to check the presence if the signed key. This may not be perfect but it is quite handy since the signed event on Informo follows a common structure that can be easily decapsulated.

Let me know what you think ;)

@vabd

This comment has been minimized.

Copy link
Member

vabd commented Nov 7, 2018

Didn't we previously agree on the fact that the events would be of the network.informo.article.SOURCE_SLUG? That way, it makes it easier to filter the request to Matrix's /sync and /messages endpoints based on the user's subscriptions in the client.

@GordonF42

This comment has been minimized.

Copy link
Member

GordonF42 commented Nov 7, 2018

This was the POC's behaviour, but changed it because of the following reasons:

  • filters allows to filter by event sender, the same way we can filter event types.
  • It is forbidden to publish articles in the name of another source. With the previous behaviour any user could send network.informo.article.ACME and client had to check whether the user was ACME or not.
  • It strengthen the relation between the source and its articles: If a source user sends an article event, it's the source's article and no one else's. There's no logical way around that requirement.
@GordonF42

This comment has been minimized.

Copy link
Member

GordonF42 commented Nov 7, 2018

One thing bothers me:
We discussed previously about setting the article's locale in the source configuration, i.e. one source always send articles in one single language, and if an entity wants to provide multilingual content they'll need to set-up multiple sources.

I think this will quickly become a mess when entities will need to create many sources with different names, like AcmeNews English, AcmeNews French, AcmeNews German, ... and currently we don't provide any easy way to know which locales are provided by ACMENews (except by judging source names). It also makes phishing a lot easier since anybody can register AcmeNews Spanish and it would look quite legit.

The phishing issue can be resolved by requiring ACMENews to act as a TA trusting its sources. I think this is patchy since a TA's original purpose is to build trust between separated organisations and not inside one single organisation.


I'd rather go for a one source and multiple localized articles approach:

  • The source declares a list of provided locales, and send all its localized articles with the same user
  • Article events contains a locale field.
  • When the user wants to subscribe to the source, they choose one or more locales, and the client hides articles in an undesired locales.
@vabd
Copy link
Member

vabd left a comment

Otherwise LGTM.

## Matrix event `network.informo.article`

This message event is meant to be sent by a source Matrix user. If the article
is signed, it **must** be wrapped into a [Signed Matrix

This comment has been minimized.

@vabd

vabd Nov 13, 2018

Member

"signed" shouldn't be capitalised.

This comment has been minimized.

@vabd

vabd Nov 19, 2018

Member

This part should be left as is until #8 gets merged. Afterwards, two issues need to be addressed:

  1. "If the article is signed" => articles are always signed
  2. No mention who signs the event

Both can be solved by removing the paragraph, or rephrasing it, since, as it currently is phrased, #8 makes it redundant.

This comment has been minimized.

@GordonF42

GordonF42 Nov 19, 2018

Member

IMO we should consider #8 merged as it will likely be merged before this PR (thus the link to the signing page)

This comment has been minimized.

@vabd

vabd Nov 20, 2018

Member

Sure, I was suggesting to do it that way (then merge master into this branch) so we can have a full picture of the page's final state.

Show resolved Hide resolved content/information-distribution/article.md Outdated
Show resolved Hide resolved content/information-distribution/article.md Outdated
Show resolved Hide resolved content/information-distribution/article.md Outdated
Show resolved Hide resolved content/information-distribution/article.md Outdated
@vabd

This comment has been minimized.

Copy link
Member

vabd commented Nov 14, 2018

I'd rather go for a one source and multiple localized articles approach:

  • The source declares a list of provided locales, and send all its localized articles with the same user

  • Article events contains a locale field.

  • When the user wants to subscribe to the source, they choose one or more locales, and the client hides articles in an undesired locales.

My concern here is that Informo is likely to be used in situations with bandwidth is very limited. This, plus considering that the use case of people wanting to read articles from a single source in more than one language would be pretty rare, and more than one almost non-existent, I really see this handling of l10n creating huge payloads sent to the user, with more than 50% of it being useless to the user it's being sent to most of the time, in situations where we want to keep payloads at minimal sizes.

On top of that, most websites available in more than one language have different websites/RSS feeds/editorial teams/etc. for each language, and centralising all of them on a single input might make add some useless complexity to the technical implementation.

One alternative way to handle l10n (which just occurred to me), and fixes both the issue of centralising localised websites of a single media and the one of providing payload of decent sizes would be to spec a new type of entity, which would be sort of "super sources" (which would not be the final name at all). This source would be the one trusted by TAs, and would declare a list of Matrix users handling the publication of every localised website. The idea would then be to place these localised sources at the same level in trust chains as their super source, since both are managed by the same organisation (or individual), in order for client implementations to make the whole thing transparent to users. Localised sources would have to emit a registration event including a signature from their super source rather than a TA. Of course, a super source could also reference itself as the publisher for a given locale (which would ease the migration for a news source opening a new website in a different language).

What would you think about that?

@GordonF42

This comment has been minimized.

Copy link
Member

GordonF42 commented Nov 16, 2018

Your super source / sub source idea does solve the problem, and I think it needs more in-depth investigation in a separate PR.

For now I think we should keep the current data model and extend it afterwards when the source data model is more mature.

@vabd

This comment has been minimized.

Copy link
Member

vabd commented Nov 19, 2018

I think it needs more in-depth investigation in a separate PR.

For now I think we should keep the current data model and extend it afterwards when the source data model is more mature.

Agreed (which is why I mentioned it in a comment rather than as part of the review).

FTR I'll start drafting a SCS for this today.

@vabd
Copy link
Member

vabd left a comment

Me being picky, lgtm otherwise.

Show resolved Hide resolved content/information-distribution/article.md
Show resolved Hide resolved content/information-distribution/article.md Outdated
Show resolved Hide resolved content/information-distribution/article.md Outdated

GordonF42 added some commits Nov 20, 2018

@vabd

vabd approved these changes Nov 21, 2018

@vabd

This comment has been minimized.

Copy link
Member

vabd commented Nov 21, 2018

lgtm, merging as it's already past the 14 day review period.

@vabd vabd merged commit 7d7a0fa into master Nov 21, 2018

vabd added a commit that referenced this pull request Nov 21, 2018

vabd added a commit that referenced this pull request Nov 21, 2018

@vabd vabd added scsp:merged and removed scsp:review labels Nov 21, 2018

vabd added a commit that referenced this pull request Nov 21, 2018

Update articles's intro made out of date by SCS #9 (SCS #12)
* Update articles's intro made out of date by SCS #9

* Move optional properties to the right part of the paragraph
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment