Skip to content
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

Phase 2: Nodes #2

Merged
merged 13 commits into from Nov 14, 2018

Conversation

Projects
None yet
2 participants
@vabd
Copy link
Member

commented Oct 31, 2018

Completion of the nodes' description page, aka the phase 2/complete form.

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

## Other types of nodes

Nodes that aren't entry nodes are named "relay nodes".

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Oct 31, 2018

Member

I suppose these relay nodes don't serve a client-to-server API? What are their purpose / what are the benefits to not serve a C2S API?

This comment has been minimized.

Copy link
@vabd

vabd Oct 31, 2018

Author Member

Act as a relay. If A can't reach B but can reach C, even if C isn't an entry node, A's information will eventually manage to reach B via C (thanks to pings).

This comment has been minimized.

Copy link
@vabd

vabd Nov 2, 2018

Author Member

I added the explanation above to the proposal in 9c1df08.

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 4, 2018

Member

My question was more: why a homeserver administrator would like to disable the C2S API?
What's the point of relay nodes when standard nodes can offer additional services with, afaik no drawbacks.

This comment has been minimized.

Copy link
@vabd

vabd Nov 4, 2018

Author Member

why a homeserver administrator would like to disable the C2S API?

Seems like there's some kind of confusion here. As defined higher in the page:

An entry node must allow guest access, and must define at least one alias to the Matrix room

A relay node is just a node that doesn't follow both rules. A personal HS (i.e. with a very restricted number of users and restricted access to its authentication mechanisms) with guest access disabled and/or no alias to the Matrix room would then be a relay node.

Regarding the reasons that could lead a HS admin to use their HS as a relay node rather than an entry node, a few examples would be that they don't want the exposure of an entry node, or they don't want to handle the load that's put on the C-S API by operating an entry node, or they want to be more restrictive about the access to the HS's C-S API, etc., but still want to contribute to Informo's network.

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 4, 2018

Member

ok, sounds legit.
I got confused thinking a relay node was a Synapse without any C2S API, but there are indeed other requirements to be an entry node.

I would change it to:

Nodes that aren't entry nodes (like a node without guest access) are named "relay nodes".

just to make clear that many homeservers can be unsuited for being an entry node.

This comment has been minimized.

Copy link
@vabd

vabd Nov 13, 2018

Author Member

Fixed in e4ac194.

@vabd

This comment has been minimized.

Copy link
Member Author

commented Nov 2, 2018

@GordonF42 all of the issues you mentioned should have been addressed by now, could you please give it another look?

{{% /notice %}}

In the event of an entry node that's currently being used becoming unreachable,
clients implementations **must** use the generated map to provide its user(s)

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 4, 2018

Member

I'd rather say should instead of must. Currently there are no ways to know if a server from the aliases list is harvesting data / phishing clients / filtering events / doing evil things / etc. Client administrators could instead provide a dynamic list of "approved" entry nodes.

Also "the generated map" refers to a map defined in another section. Should be something like "the map generated from the room aliases list"

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 4, 2018

Member

In the same topic, I was thinking that it could be nice to let TAs trust / blacklist some entry nodes the same way they can trust / blacklist other TAs and sources, in order to curate the raw alias-generated list

This comment has been minimized.

Copy link
@vabd

vabd Nov 4, 2018

Author Member

I'd rather say should instead of must. Currently there are no ways to know if a server from the aliases list is harvesting data / phishing clients / filtering events / doing evil things / etc. Client administrators could instead provide a dynamic list of "approved" entry nodes.

Right, you've got a point here.

Also "the generated map" refers to a map defined in another section. Should be something like "the map generated from the room aliases list"

Indeed.

In the same topic, I was thinking that it could be nice to let TAs trust / blacklist some entry nodes the same way they can trust / blacklist other TAs and sources, in order to curate the raw alias-generated list

That could be a great idea. It doesn't belong to this SCS, though.

I'll be making the changes later today or sometime next week.

This comment has been minimized.

Copy link
@vabd

vabd Nov 13, 2018

Author Member

Fixed in 8cd78b1.

Sorry for the delay.

@vabd

This comment has been minimized.

Copy link
Member Author

commented Nov 13, 2018

@GordonF42 Could you please have another (and hopefully final) look at this?

@GordonF42
Copy link
Member

left a comment

One typo and one link suggestion ;)

Show resolved Hide resolved content/information-distribution/node.md Outdated
room, they are still useful as they can relay articles to other nodes that are
out of reach from the articles' emitter(s). For example, if a node `A` can't
reach a node `B` but can reach a node `C`, even if `C` isn't an entry node,
`A`'s information will eventually manage to reach `B` via `C` thanks to pings.

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 13, 2018

Member

Maybe point to some Matrix documentation? (I guess it's related to backfilling and https://matrix.org/docs/spec/server_server/unstable.html#post-matrix-federation-v1-get-missing-events-roomid?)

This comment has been minimized.

Copy link
@vabd

vabd Nov 13, 2018

Author Member

Good idea (though this isn't the right endpoint). Fixed in dcfc2b8.

GordonF42 and others added some commits Nov 13, 2018

Typo
Co-Authored-By: vabd <34184120+vabd@users.noreply.github.com>
@@ -31,12 +31,15 @@ messages timeline and [request the missing message from
`C`](https://matrix.org/docs/spec/server_server/unstable.html#post-matrix-federation-v1-get-missing-events-roomid).

In order to avoid a node being left out of a federation, nodes **must** send out
a small message, named "ping" (2️⃣), to the Matrix room every twelve hours. This
a small message, named "ping", to the Matrix room every twelve hours. This
way, a node that's cut from most of a federation except for a few nodes will end
up getting all of the information it missed. If a node is offline when it is
supposed to send out a ping it **should** send it as soon as it gets back
online.

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 13, 2018

Member

I would have added:

Internally, sending pings triggers the [Matrix's `get_missing_events` federation
endpoint](https://matrix.org/docs/spec/server_server/unstable.html#post-matrix-federation-v1-get-missing-events-roomid)
and forces the Matrix server to query known federated servers to retrieve missing data.

This comment has been minimized.

Copy link
@vabd

vabd Nov 13, 2018

Author Member

Actually, the reference to that endpoint is already mentioned in the page line 31, I didn't notice it. Therefore, I'm not adding that.

reach a node `B` but can reach a node `C`, even if `C` isn't an entry node,
`A`'s information will eventually manage to reach `B` via `C` thanks to pings.
This is done through [Matrix's `get_missing_events` federation
endpoint](https://matrix.org/docs/spec/server_server/unstable.html#post-matrix-federation-v1-get-missing-events-roomid).

This comment has been minimized.

Copy link
@GordonF42

GordonF42 Nov 13, 2018

Member

Remove this if you add the thing line 38

This comment has been minimized.

Copy link
@vabd

vabd Nov 13, 2018

Author Member

Fixed in 1560426.

@GordonF42

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

lgtm ! :)

@vabd

This comment has been minimized.

Copy link
Member Author

commented Nov 13, 2018

Awesome! 🎉
Will merge tomorrow as the public review period is ends then :)

@vabd vabd merged commit 1202456 into master Nov 14, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.