3 ms·

> but there wasn't any hierarchy as such. My memory was that smaller ISPs would peer from the larger ISPs, that's the type of hierarchy I was thinking of. May

> but there wasn't any hierarchy as such. My memory was that smaller ISPs would peer from the larger ISPs, that's the type of hierarchy I was thinking of. Maybe not in design, but in practice.

shagie 3y ago
That's a matter of pipes and storage. They could peer to each other. There were a number of private hierarchies (including my favorite - the bofh.* one) that had different peering relationships. http://usenet.trigofacile.com/hierarchies/index.py?status=private http://usenet.trigofacile.com/hierarchies/index.py?status=pr... and https://web.archive.org/web/20220815151921/http://bofh.taronga.com/bofh.html https://web.archive.org/web/20220815151921/http://bofh.taron... Peering to larger ISPs was more of a matter of convince and that is often part of a business arrangement for a company and a client. Another use of usenet back in the day SGI had its bug tracker write out to news. A Usenet reader was one of the preferred interfaces to creating and commenting on bugs internally. Furthermore, exporting the bug tracking system to a partner was "simply" a matter of adding them to the feed and making sure that they didn't route bugs from their server to others. The point is that the "little to big to bigger" was just convince - not code or enforced in any way. Many university CS departments would peer with each other back in the day. Recall that news was originally across UUCP - the same mechanism that email was sent. If you wanted to send email to someone at another university you'd much rather have them as a peer so that it was just one hop rather than going some other route that could take days to get there. And so various hub and spokes evolved. Everything in the University of Wisconsin peered with Madison. Everything in Illinois peered with UIUC and Madison peered with UIUC. Note the word 'peer'. And if UW Whitewater wanted to get their email to UIC faster, then they would peer too. Would UW Madison complain that it's not going through them? Not at all! It meant their phone bills would be less.
- PrimeMcFly 3y ago
  > The point is that the "little to big to bigger" was just convince - not code or enforced in any way. But the same thing may well happen again, and that's a kind of flaw. A truly decentralized system to combat the things we want it to combat should enforce or be resistant to any de facto hierarchies.
  - shagie 3y ago
    You are attempting to enforce what would likely be a sub-optimal network structure which in turn increases the cpu, network, and storage costs that an individual/small group may see as too expensive. That in turn leads most people to head to the main/largest instance of the given part of the federated network which is even more of a risk. If you try to enforce this, you will get mastodon.social and a much of larger-smaller sites rather than hundreds of even smaller federated sites. It becomes too expensive for the small sites to federate with all of them (you'll note that turn key hosted instances of mastodon often have limits to how many different sites they can federate with). The famous quote of "The Net interprets censorship as damage and routes around it." is from Usenet. It took very concerted efforts in order to moderate or completely censor a badly behaving site. I would contend that usenet did a very good job of handling its robustness of delivery that didn't involve spending too much time for a given site to try to peer everywhere.

> but there wasn't any hierarchy as such. My memory was that smaller ISPs would peer from the larger ISPs, that's the type of hierarchy I was thinking of. Maybe not in design, but in practice.

shagie 3y ago

That's a matter of pipes and storage. They could peer to each other. There were a number of private hierarchies (including my favorite - the bofh.* one) that had different peering relationships. http://usenet.trigofacile.com/hierarchies/index.py?status=private http://usenet.trigofacile.com/hierarchies/index.py?status=pr... and https://web.archive.org/web/20220815151921/http://bofh.taronga.com/bofh.html https://web.archive.org/web/20220815151921/http://bofh.taron... Peering to larger ISPs was more of a matter of convince and that is often part of a business arrangement for a company and a client. Another use of usenet back in the day SGI had its bug tracker write out to news. A Usenet reader was one of the preferred interfaces to creating and commenting on bugs internally. Furthermore, exporting the bug tracking system to a partner was "simply" a matter of adding them to the feed and making sure that they didn't route bugs from their server to others. The point is that the "little to big to bigger" was just convince - not code or enforced in any way. Many university CS departments would peer with each other back in the day. Recall that news was originally across UUCP - the same mechanism that email was sent. If you wanted to send email to someone at another university you'd much rather have them as a peer so that it was just one hop rather than going some other route that could take days to get there. And so various hub and spokes evolved. Everything in the University of Wisconsin peered with Madison. Everything in Illinois peered with UIUC and Madison peered with UIUC. Note the word 'peer'. And if UW Whitewater wanted to get their email to UIC faster, then they would peer too. Would UW Madison complain that it's not going through them? Not at all! It meant their phone bills would be less.

PrimeMcFly 3y ago
> The point is that the "little to big to bigger" was just convince - not code or enforced in any way. But the same thing may well happen again, and that's a kind of flaw. A truly decentralized system to combat the things we want it to combat should enforce or be resistant to any de facto hierarchies.
- shagie 3y ago
  You are attempting to enforce what would likely be a sub-optimal network structure which in turn increases the cpu, network, and storage costs that an individual/small group may see as too expensive. That in turn leads most people to head to the main/largest instance of the given part of the federated network which is even more of a risk. If you try to enforce this, you will get mastodon.social and a much of larger-smaller sites rather than hundreds of even smaller federated sites. It becomes too expensive for the small sites to federate with all of them (you'll note that turn key hosted instances of mastodon often have limits to how many different sites they can federate with). The famous quote of "The Net interprets censorship as damage and routes around it." is from Usenet. It took very concerted efforts in order to moderate or completely censor a badly behaving site. I would contend that usenet did a very good job of handling its robustness of delivery that didn't involve spending too much time for a given site to try to peer everywhere.