Стандартная схема адресации в сети Фидонет описывается в документе FTSC FRL-1002. Стандарт предусматривает полную форму записи адреса (так называемая 5D-адресация — англ. 5D-addressing, использующая 5 полей сетевого адреса) и различные формы сокращённой записи, из которых наиболее часто используемыми являются 3D и 4D-адресации. 5D-адреса записывается в следующей форме: Zone:Net/Node.Point@Domain, где:
i. Zone — номер зоны (от 1 до 32767).
ii. Net — номер сети (от 1 до 32767).
iii. Node — номер узла (от −1 до 32767).
iv. Point — номер пойнта узла (от 1 до 32767).
v. Domain — символьное имя сети (до 8 знаков).
Из этих полей обязательными являются только Net и Node. Таким образом, возможны следующие сокращённые формы записи адреса:
i. Zone:Net/Node.Point — 4D-адресация, имя сети по умолчанию fidonet.
ii. Zone:Net/Node — 3D-адресация, опускается поле Point, которое у всех узлов сети имеет значение 0.
iii. Net/Node — 2D-адресация, опускается поле Zone, для которого по умолчанию принимается значение 1.
Значение номера узла «-1» используется для отправки запроса на получение сетевого адреса. Символьное имя сети используется достаточно редко ввиду маловероятности конфликтов адресации между парами зона‐узел у участников FTN-сетей, и наличия популярного ПО, не учитывающего домен при сравнении адресов.
Устав Фидонета требует, чтобы каждый узел сети поддерживал в актуальном состоянии список всех узлов сети (нодлист, англ. nodelist). Формат списка узлов описывается стандартом Фидонет FTS-5000. Информация об узле, указанная в списке, включает в себя статус узла (для обозначения временно неработающих и недоступных средствами телефонии узлов), его номер и наименование (для узлов, доступных посредством интернет-протоколов — доменное имя, IP или E-mail адрес), географическое местонахождение, имя и фамилию оператора узла, номер телефона и флаги, указывающие на возможности программного и аппаратного обеспечения узла. Список узлов еженедельно обновляется. Координаторы каждой сети поддерживают в актуальном состоянии локальные списки узлов. Эти списки регулярно пересылаются вышестоящим координаторам, которые составляют общесетевой список узлов. Изменения в списке рассылаются (как правило, через файловые эхоконференции) всем узлам сети.
По концепции Фидонета и по Полиси отправить письмо можно двумя способами: либо директом (то есть непосредственно получателю), либо сетевому координатору получателя, который обязан организовать дальнейшую доставку полученной им почты членам своей сети (обычно либо непосредственно, либо, в больших сетях, через хабы). Такая схема неудобна в сети с большим числом узлов и для передачи информации зачастую требует междугородных и международных телефонных вызовов. Ввиду этого обычной практикой стало заключение неформальных договоренностей между системными операторами о том, что один или несколько узлов сети принимают на себя функции по маршрутизации сетевых сообщений. Кроме того, на уровне зоны выделялись узлы, бравшие на себя функцию передачи почты в другие зоны (межзонные гейты — англ. zone gate). Часто системные операторы этих узлов также являлись одновременно координаторами своего уровня или крупными хабами, но это не являлось обязательным требованием. Выполнение функций такими узлами зачастую требовало значительных материальных затрат, поэтому в таких случаях могло вводиться разделение расходов между всеми узлами сети (англ. costsharing). Использовались и другие возможности: так, с ноября 1991 года передача сообщений между Европой и Северной Америкой, а с 1992 года и между другими регионами (Тайвань, ЮАР, Чили и т.д.) стала осуществлялась с использованием IP-каналов. В России подобные функции нередко выполняли узлы, чьи системные операторы использовали служебное положение для осуществления междугородних звонков без оплаты, в том числе через ведомственные сети (Искра-2, железнодорожная сеть). Такие узлы получили название «лонглинки» (от англ. long link). Фактически схема маршрутизации была иерархична, а количество горизонтальных связей было мало. Это позволяло обходиться без специальных технических средств, позволяющих организовать маршрутизацию сообщений. Однако с ростом количества узлов, а также с распространением IP количество лонглинков сильно увеличилось, что сделало традиционную схему роутинга неэффективной (по крайней мере, в российском сегменте сети). Кроме того, для повышения надёжности сети необходима была децентрализация роутинга с образованием так называемого «бекбона» (англ. backbone) сети. Для оптимизации схемы роутинга у узлов с большим количеством связей с другими узлами было предложено два решения:
i. Протокол FRIP (расшифровывается как Fidonet routing information protocol) и одноимённая утилита, созданная Дмитрием Завалишиным, работающая по принципу «объявления» — каждый узел рассылает связанным с ним узлам объявления о том, что он готов принимать почту для некоего списка узлов (как правило, для самого себя и своих даунлинков). Получатели объявления продолжают рассылать его всем связанным узлам. Рассылка не происходит, если получатель объявления уже «знает» более короткий путь к целевому узлу. В результате должна быть автоматически построена карта роутинга, обеспечивающая доставку сообщений по наиболее короткому пути. В настоящее время этот протокол не используется.
ii. Программа Hubroute generator (также известная как «сафроутер» — по имени создателя, Юрия Сафронова). Эта программа строит роутинг на основе общих для региона списка жестко заданных путей роутинга и списка «доверенных» узлов, принимающих почту для определённой сети (в российском Фидонет — R50.ROU и R50.TRU соответственно) с учётом данных об узлах, на которые данный узел может напрямую отправлять сообщения. Общерегиональные списки путей роутинга и доверенных узлов составляются региональным координатором на основании данных, которые ему присылают сетевые координаторы.
Практически все основные протоколы и форматы, используемые в Фидонете, стандартизированы и записаны в FTS (FidoNet Technical Standards — технические стандарты Фидонета), их сбором и стандартизацией занимается FTSC (FidoNet Technical Standards Committee — комитет по техническим стандартам Фидонета). Исторически основным техническим стандартом Фидонет являлся FTS-0001, устанавливающий базовые требования, которым должны были соответствовать все системы. Стандарт описывает требования к реализации всех уровней протоколов обмена в соответствии с сетевой моделью ВОС, за исключением физического уровня. На канальном уровне для передачи данных использовался протокол XMODEM. FTSC также были приняты следующие основные стандарты и документы:
i. FTS-0004: The Conference Mail System (EchoMail Specification) — описывает принципы построения системы эхоконференций
ii. FTS-1024: Raw ifcico mail transfer protocol — описывает протокол ifcico, предназначенный для передачи данных через надёжные соединения (такие, как TCP/IP-каналы).
iii. FTS-1026: Binkp/1.0 Protocol specification — содержит описание протокола binkp, применяемого для передачи данных с использованием TCP/IP.
iv. FTS-5000: The distribution nodelist — определяет формат списка узлов сети
v. FSC-0056: EMSI/IEMSI Protocol Definitions — описывает протокол установления соединения (хендшейка) EMSI.
vi. FSC-0072: The HYDRA file transfer protocol — включает спецификации протокола передачи данных Hydra.
FTSC также создаёт реестр программных продуктов, участвующих в обмене информацией в Фидонет (мейлеров и эхопроцессоров). Последний раз реестр обновлялся в январе 2005 года. Первой программой, включённой в реестр, является Fido Тома Дженнингса, ей присвоен код 0000; последней — трекер RNtrack с кодом 16FF.
Фидонет имеет иерархическую структуру, описанную в пунктах 1.2.3—1.2.8 Устава Фидонет. Организационным объединением нижнего уровня является сеть, сети объединяются в регионы, а регионы в зоны. У каждого уровня есть свой координатор. Координаторы сетей и регионов (NC и RC — англ. Network Coordinator, Regional Coordinator) назначаются вышестоящим координатором, координаторы зон (ZC, англ. Zone Coordinator) избираются координаторами регионов. Координаторы зон являются членами Совета координаторов зон, решающего вопросы, касающиеся сети в целом. Председателем Совета является международный координатор (IC, англ. International Coordinator). Международный координатор является гарантом законности проведения выборов и референдумов в сети, оглашает решения Совета, а также выполняет функции по составлению общемирового списка узлов. Международный координатор выбирается Советом координаторов зон. Процедура выборов всегда вызывала большие разногласия, вследствие чего этот пост часто оказывался вакантным. В 2000 году международным координатором был избран Z2C (координатор зоны 2) Вард Досше (нем. Ward Dossche). В 2004 году совет координаторов зон заявил о смещении его с поста и о избрании международным координатором Z3C Малькольма Майлса (англ. Malcolm Miles). Досше не согласился с этим решением, указав, что голоса при выборах должны распределяться не по схеме «один координатор — один голос», а в зависимости от числа узлов в соответствующей зоне. При такой схеме ему, как координатору самой большой, второй зоны, должно было принадлежать 89 голосов, а всем остальным координаторам в сумме — 11 голосов. Следствием этого стало параллельное существование двух международных координаторов: избранного советом координаторов Малькольма Майлса и Варда Досше, который отказался уходить с поста. Координаторы могут делегировать часть своих полномочий другим узлам. Обычно делегируются полномочия по организации доставки эхоконференций (сетевому или региональному эхокоординатору — NEC или REC) и файлового трафика (сетевому или региональному файлэхокоординатору — NFEC или RFEC)