3 ms·

> Usenet, I think, has a strong hierarchy structure rather than just being a 'web', although it is that as well. So if the takedown order is directed at a serve

by shagie 3y ago

> Usenet, I think, has a strong hierarchy structure rather than just being a 'web', although it is that as well. So if the takedown order is directed at a server in high enough position, it is essentially removes it from all of Usenet - and it's not just takedown orders, but actors with the ability to remove content unilaterally. There were some sites that had bigger pipes and more tolerance for storage requirements than others, and it was thus easier to peer to one of those big ones to route posts that would get out everywhere else faster - but there wasn't any hierarchy as such. The hierarchy of unset was in the naming - not the organization of how things were routed nor for a "who controls that." There is no lumber cartel forcing spammers to print out things and buy paper. However, if a site misbehaves often enough it gets shunned sufficiently through per user kill files and admins not accepting posts that originated or passed through some server. If you were to take down a big server that lots of people routed through, they'd route around it or another would take its place. Taking down The Pirate Bay didn't stop bit torrent.

PrimeMcFly 3y ago
> 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.

by shagie 3y ago

PrimeMcFly 3y ago

> 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.