Русский
Русский
English
Статистика
Реклама

Protocols

MQTTv5.0 Обзор новых функций

30.06.2020 22:17:55 | Автор: admin
Привет всем любителям IoT и железок!

В этой статье я расскажу про, пожалуй, самый популярный протокол передачи данных, используемый в сфере Интернета вещей, MQTT. А если конкретнее, то про MQTT Version 5.0 (версия, опубликованная 7 марта 2019 года). А если еще конкретнее, про приятные нововведения версии 5.0 по сравнению с версией 3.1.1.

Кстати, а почему v5.0? Куда делась версия v4.0?

Коренная причина лежит в заголовке пакета CONNECT. Версия протокола или, если быть более точным, уровень версии протокола устанавливается в байте 7.




The 8-bit unsigned value that represents the revision level of the protocol used by the Client. The value of the Protocol Level field for the version 3.1.1 of the protocol is 4 (0x04).



Уровень протокола v3.1 определяется как 3, а v3.1.1 4. Следовательно, следующий уровень протокола 5. Чтобы избежать несоответствия, группа спецификации согласилась назвать следующую версию MQTTv5.0:

The value of the Protocol Version field for version 5.0 of the protocol is 5 (0x05).

По словам (от 11 декабря 2019 года) Lee Stacey, product evangelist at Thingstream, скоро MQTT будет основным протоколом обмена данными между датчиками.

В настоящее время устройства IoT используют разные протоколы обмена сообщениями, например: XMPP, AMQP, DDS. Такая фрагментация была препятствием для прогресса в IoT с самого начала.

Протоколы обмена сообщениями одна из областей, где требуется стандартизация.

Вероятно, лидирующую позицию займет MQTT. Он существует уже более 25 лет, прост, потребляет мало энергии в сочетании с другими преимуществами это делает его идеальным стандартом для IoT. Дополнительные функции, добавленные в MQTT для ретрансляции данных из сенсорных сетей, позволяют IoT-устройствам использовать для отправки сообщений еще меньше энергии.


А раз такое дело, то мне была поставлена задача внедрить поддержку пятой версии MQTT в один из сервисов архитектуры платформы Интернета вещей. Пришлось изучить довольно много страниц протокола, так что спешу поделиться своими наработками и понимаем происходящего.

Прим. Далее по тексту буду называть topic топиком, а payload полезной нагрузкой.

Наиболее важно, что MQTTv5.0 не имеет обратной совместимости (как v3.1.1). Очевидно, что введено слишком много нового, поэтому необходимо пересмотреть существующие реализации.

Согласно спецификации, MQTT v5.0 добавляет значительное количество новых функций в MQTT, сохраняя большую часть ядра на месте.

Основные функциональные цели MQTTv5.0:

  • улучшение для крупномасштабных систем в отношении установления связи с тысячами и миллионами устройств;
  • улучшение составления отчетов об ошибках (код причины и строка причины);
  • формализация общих паттернов взаимодействия, включая определение возможностей взаимодействующих устройств и ответы на запросы;
  • добавление механизмов расширяемости, включая пользовательские свойства, формат полезной нагрузки и тип контента;
  • увеличение производительности и улучшенная поддержка для небольших клиентов.

Основные новые функции можно разделить, для наглядности, на следующие группы:

1. Особенности подключения
  • Расширенная аутентификация (Enhanced authentication)
  • Истечение сеанса (Session expiration)
  • Клиентские и серверные ограничения (Client and Server restrictions/limitations)
  • Интервал задержки Will Message (Will Delay Interval)
  • Перенаправление сервера (Server Reference or Server Redirect)

2. Особенности публикации сообщений
  • Интервал истечения сообщения (Message Expiry Interval)
  • Индикатор формата полезной нагрузки и тип содержимого (Payload format indicator & Content type)
  • Псевдонимы для топиков (Topic Aliases)
  • Ответ на запрос (Response Topic)

3. Особенности подписки
  • Отсутствие локальных публикаций (Non local publishing)
  • Контроль сохраненных сообщений (Retained message control)
  • Идентификатор подписки (Subscription identifier)
  • Общие подписки (Shared subscriptions)

4. Общие особенности
  • Коды и строки причин на все ACK-сообщения (Reason codes on all ACK messages)
  • Отключение сервера (Server disconnect)
  • Пользовательские свойства (User properties)


Особенности подключения


Расширенная аутентификация (см. п. 4.12 в спецификации)


В MQTTv5.0 теперь доступны дополнительные методы аутентификации, помимо имени пользователя и пароля как в MQTTv3.1.1 (см. свойства Authentication Method и Authentication Data).

Истечение сеанса


В MQTTv3.1.1 и более ранних версиях клиент может управлять тем, как сервер обрабатывает сеанс клиента (сеанс означает подписку клиента и любые сообщения в очереди) с помощью флага чистый сеанс. Если установлено значение 1, сервер удалит любой существующий сеанс для этого клиента и не сохранит сеанс после отключения. Если установлено значение 0, сервер восстановит любой существующий сеанс для клиента при повторном подключении и сохранит сеанс при отключении клиента.

В MQTTv5.0 этот механизм в основном сохранился, за исключением того, что теперь появился таймер истечения сеанса (см. свойство Session Expiry Interval). Если флаг установлен как false, нужно указать значение окончания сеанса. Если этого не сделать, будет установлено значение 0, что делает соединение таким же, как если бы значение чистого сеанса было установлено как true.

Например, можно установить время истечения сеанса 300 секунд. Это означает, что если клиент отключается и повторно подключается в течение 5 минут со значением чистого сеанса false, QOS > 1, то данные состояния сеанса (например, подписка на топики, сообщения в очереди) сохраняются. Однако, если клиент отключается и повторно подключается по истечении 5 минут с теми же настройками, данные о состоянии сеанса удаляются и клиент должен повторно подписаться на топики, а сообщения, отправленные во время отсоединения клиента, теряются.

Клиентские ограничения


Клиент теперь может указывать серверу следующие ограничения:

  • по размеру сообщений для отправки (см. свойство Maximum Packet Size),
  • по количеству сообщений QOS 1 и 2 (см. свойство Receive Maximum).

Ограничение размера сообщений

Клиент сообщает серверу максимальный размер сообщения, которое он готов получить, и любые сообщения, превышающие это значение, отбрасываются сервером. Используется маломощными клиентами, которым не хватает памяти для хранения сообщений.

Ограничение количества сообщений

Клиент сообщает серверу об ограничении количества сообщений QOS 1 и 2, которые могут быть отправлены одновременно. Также используется маломощными клиентами, поскольку сообщения QOS 1 и 2 означают, что клиент должен отправить дополнительные сообщения подтверждения.

Серверные ограничения


Предоставление определенных функций может привести к нагрузке на серверные ресурсы, поэтому сервер может их не поддерживать. Теперь сервер может указать это, используя поле свойств.

Например, в сообщении CONNACK сервер может указать максимальное значение псевдонима топика (см. свойство Topic Alias Maximum) и время истечения сеанса (см. свойство Session Expiry Interval).

Интервал задержки Will Message


Используется для указания временной задержки (см. свойство Will Delay Interval) при отправке Will Message, предотвращая отправку сообщения при коротком прерывании соединения.

Перенаправление сервера (см. п. 4.11 в спецификации)


Это очень интересная функция, поскольку она позволяет серверу перенаправлять клиента к другому брокеру/серверу (см. свойство Server Reference).


Особенности публикации сообщений


Интервал истечения сообщения


Когда сообщение публикуется с QOS 1 или 2 и клиент-получатель имеет:

  1. чистый сеанс false,
  2. подписку с QOS 1 или 2,

брокер будет хранить опубликованные сообщения для клиента, если он в данный момент отключен.

Тем не менее можно установить период, в течение которого сервер будет сохранять это сообщение. Например, указать значение свойства Message Expiry Interval равным 20. При такой настройке, если клиент-получатель не подключится в течение 20 секунд, сообщение удалится.

Индикатор формата полезной нагрузки и тип содержимого


Индикатор формата полезной нагрузки устанавливается при публикации сообщения (см. свойство Payload Format Indicator) как один из двух вариантов:

  1. бинарный то же самое, что в v3.1,
  2. строка UTF-8 новая возможность v5.

Функция полезна для получателя, чтобы узнать, нужно ли ему декодировать полезную нагрузку сообщения.

Также при публикации сообщений можно указать тип содержимого в стиле MIME (см. свойство Content Type).

Псевдонимы для топиков


Псевдонимы являются механизмом уменьшения размера публикуемых пакетов за счет уменьшения размера топика.

Созданный псевдоним топика можно использовать вместо самого топика. Если у топика homes/house1/upstairs/light1 есть псевдоним 1 (см. свойство Topic Alias), то это число можно использовать вместо строки топика при публикации сообщений.

Прежде чем использовать псевдонимы топиков, клиент должен указать максимальное количество псевдонимов (см. свойство Topic Alias Maximum) для сервера. По умолчанию, если это не установлено, псевдонимы топиков клиентом не используются.

Ответ на запрос


В веб-приложениях клиент(браузер) делает запрос, а сервер отвечает. В то же время MQTT использует шаблон публикации и подписки, где нет прямой связи между отправляющим и получающим клиентом.




Использование топика для ответа (см. свойство Response Topic) в сообщении публикации позволяет реализовать шаблон запроса/ответа, распространенный в веб-приложениях. Таким образом создается виртуальное соединение между клиентами, так что один из клиентов может функционировать как традиционный сервер, хотя пакеты всё так же проходят через брокера.





Особенности подписки


Отсутствие локальных публикаций


В MQTTv3.1.1, если вы подписались на топик, по которому публикуете сообщения, вы получите все сообщения, которые вы публикуете. Используя опцию отсутствия локальных публикаций, можно избежать того, чтобы брокер отправлял вам сообщения, которые вы сами же и опубликовали.

Контроль сохраненных сообщений


Сохраненные сообщения по-прежнему работают, как в версии 3.1.1, но теперь добавлены параметры подписки для управления тем, что получает клиент:
  • 0 отправить сохраненные сообщения, когда клиент подписывается. То же, что и в MQTT 3.1.1,
  • 1 отправить сохраненные сообщения, когда клиент подписывается, если подписка в настоящее время не существует.
  • 2 не отправлять сохраненные сообщения, когда клиент подписывается.

Идентификатор подписки


При подписке можно указывать идентификатор (см. свойство Subscription Identifier), соответствующий этой подписке. Тогда при получении сообщения клиент имеет возможность определить, какая подписка или подписки привели к доставке сообщения.

Общие подписки (см. п. 4.8.2 в спецификации)


Идея заключается в том, чтобы обеспечить балансировку нагрузки клиента. При обычных подписках (не общих подписках), если, например, 4 клиента подписываются на один и тот же топик и клиент публикует сообщение с таким топиком, то сообщение отправляется всем 4 подписавшимся клиентам.




При общей подписке сообщение будет отправлено только одному из подписавшихся клиентов.




Топик для такой подписки должен начинаться с ключевого слова $share.

Формат фильтра топиков следующий:
$share/{ShareName}/{filter}
$share служебное слово, символьная строка, которая помечает фильтр топиков как фильтр топиков общей подписки
{ShareName} название подписки, символьная строка, которая не должна включать "/", "+" или "#"
{filter} то же самое, что топик в обычных подписках

Пример:

4 клиента подписываются на $share/group1/my/topic, 3 клиента подписываются на $share/group2/my/topic, и 3 клиента подписываются по обычной подписке (2 my/topic и 1 по wildcard подписке my/#).

Затем, если клиент публикует сообщение для топика my/topic:

  1. 1 сообщение отправлено одному из клиентов, подписавшихся на $share/group1/my/topic
  2. 1 сообщение отправлено одному из клиентов, подписавшихся на $share/group2/my/topic
  3. 3 сообщения отправлено клиентам с обычной подпиской

Таким образом, в общей сложности 5 сообщений отправляются клиентам.





Общие особенности


Коды и строки причин на все ACK-сообщения


В MQTTv3.1.1 было очень мало указаний от сервера относительно того, что пошло не так на разных этапах:

  • установление связи,
  • публикация сообщения,
  • подписка на топики.

Теперь все пакеты подтверждения (кроме PINGRESP) содержат код причины, доступно 128 кодов. Приложению становится намного проще понять, что же произошло, и предпринять соответствующие действия.

Например, публикация ACK с кодом причины 16 означает, что нет подходящих подписчиков. Поэтому в MQTTv5 можно определить, в какой степени используется тот или иной топик.

Следует помнить, что коды причины являются необязательными, сервер/брокер все еще может решить просто отключить клиентов как в MQTTv3.1.1, например, по соображениям безопасности.

В дополнение к коду причины строка причины может быть связана с ответом, чтобы предоставить более удобочитаемое сообщение.

Отключение сервера


В MQQTv3.1.1 только клиент может отправить сообщение об отключении. Если сервер столкнулся с проблемами, он просто прервал бы сеанс TCP/IP. В MQTTv5 сервер может отправить клиенту сообщение о разъединении вместе с кодом причины (ошибка протокола, неавторизованное подключение и т.д.).

Примеры кодов причины из спецификации (см. п. 3.14.2.1 в спецификации):




Пользовательские свойства


Добавлены во все типы пакетов. Они определяются пользователем и представляют собой набор пар ключ-значение (см. свойство User Property). Полезны для отправки информации за рамками полезной нагрузки, в то время как в 3.1.1 любая информация отправлялась как часть полезной нагрузки.

Пользовательские свойства, как и все другие свойства, пересылаются брокером от отправителя получателя без изменений и в том же порядке. Может быть добавлено неограниченное количество пользовательских свойств.

Заключение


Пока на этом всё. В следующей статье я проведу подробный разбор всех свойств, добавленных в спецификацию.
Подробнее..

MQTTv5.0 Обзор новых функций. Часть 2

26.09.2020 22:13:23 | Автор: admin
Всем привет!

Приведенный ниже материал является продолжением статьи о функционале, добавленном в новой версии MQTTv5.0. Если вы уже успели ее изучить, то для вас не составит труда заметить, что большинство новых функций базируется на понятии свойств, которые можно добавлять в пакет. В этой статье мы подробно их разберем.

Прим. Статья направлена на тех, кто имеет интерес или необходимость глубоко погружаться в тонкости MQTT. Здесь не будет картинок и лирических отступлений, только хардкор!!!

Далее приведена таблица всех свойств (см. п. 2.2.2.2 в спецификации).

ID Название Тип данных Пакет / Will Properties
1 PayloadFormatIndicator Byte PUBLISH, Will Properties
2 MessageExpiryInterval FourByteInteger PUBLISH, Will Properties
3 ContentType UTF-8Encoded String PUBLISH, Will Properties
8 ResponseTopic UTF-8Encoded String PUBLISH, Will Properties
9 CorrelationData BinaryData PUBLISH, Will Properties
11 SubscriptionIdentifier VariableByteInteger PUBLISH, SUBSCRIBE
17 SessionExpiryInterval FourByteInteger CONNECT, CONNACK, DISCONNECT
18 AssignedClientIdentifier UTF-8Encoded String CONNACK
19 ServerKeepAlive TwoByteInteger CONNACK
21 AuthenticationMethod UTF-8Encoded String CONNECT, CONNACK, AUTH
22 AuthenticationData BinaryData CONNECT, CONNACK, AUTH
23 RequestProblem Information Byte CONNECT
24 WillDelayInterval FourByteInteger WillProperties
25 RequestResponse Information Byte CONNECT
26 ResponseInformation UTF-8Encoded String CONNACK
28 ServerReference UTF-8Encoded String CONNACK, DISCONNECT
31 ReasonString UTF-8Encoded String CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, AUTH
33 ReceiveMaximum TwoByteInteger CONNECT, CONNACK
34 TopicAliasMaximum TwoByteInteger CONNECT, CONNACK
35 TopicAlias TwoByteInteger PUBLISH
36 MaximumQoS Byte CONNACK
37 RetainAvailable Byte CONNACK
38 UserProperty UTF-8String Pair CONNECT, CONNACK, PUBLISH, Will Properties, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, DISCONNECT, AUTH
39 MaximumPacketSize FourByteInteger CONNECT, CONNACK
40 WildcardSubscription Available Byte CONNACK
41 SubscriptionIdentifier Available Byte CONNACK
42 SharedSubscription Available Byte CONNACK


Теперь давайте рассмотрим их поподробнее.


Payload Format Indicator индикатор формата полезной нагрузки


  • 0 данные являются набором неопределенных байт, что эквивалентно отсутствию отправки индикатора формата полезной нагрузки,
  • 1 данные представляет собой кодированные символьные данные UTF-8.


Message Expiry Interval интервал истечения сообщения


Число, представляющее интервал истечения срока действия сообщения (в секундах).

Если интервал истечения срока действия сообщения прошел и серверу не удалось доставить сообщение соответствующему абоненту, он должен удалить сообщение для этого абонента.


Content Type тип содержимого


Значение типа содержимого определяется отправляющим и получающим клиентом.


Response Topic топик для ответа


Строка UTF-8, которая используется в качестве топика для ответного сообщения.

Получатель сообщения с указанным топиком для ответа отправляет свой ответ, используя этот топик как топик своей публикации.

Взаимодействие запрос/ответ в этом случае происходит следующим образом (см. п. 4.10.1 в спецификации):

  1. Клиент (отправитель) публикует сообщение запроса с некоторым топиком, в котором указан топик для ответа.
  2. Другой клиент (получатель) предварительно подписывается на фильтр топиков, который соответствует имени топика, использовавшегося при публикации сообщения запроса. В результате он получает сообщение запроса. Может быть несколько клиентов, подписанных на этот топик или может не быть вовсе.
  3. Отвечающий клиент выполняет соответствующее действие на основе полученного сообщения, а затем публикует сообщение ответа с тем топиком, который был указан в свойстве с топиком ответа.
  4. При типичном использовании запрашивающая сторона предварительно подписывается на топик ответа и тем самым получает ответное сообщение. Однако какой-то другой клиент может быть подписан на топик ответа и в этом случае ответное сообщение также будет получено и обработано этим клиентом. Если при отправке ответного сообщения нет подписчиков на топик ответа, ответное сообщение не будет доставлено ни одному клиенту.


Correlation Data корреляционные данные


Данные корреляции используются отправителем сообщения запроса, чтобы определить, к какому запросу относится сообщение ответа, когда оно получено. Если данные корреляции отсутствуют, то запрашивающая сторона не требует никаких данных корреляции.

Если сообщение запроса содержит корреляционные данные, получатель должен также включить эти корреляционные данные в качестве свойства в пакет PUBLISH ответного сообщения.

Значение данных корреляции имеет значение только для отправителя сообщения запроса и получателя сообщения ответа.


Subscription Identifier идентификатор подписки


Число, представляющее идентификатор подписки.

Если публикация является результатом совпадения с более чем одной подпиской, будут указаны несколько идентификаторов подписки, в этом случае их порядок не имеет значения.

Клиент также может сделать несколько подписок, соответствующих данной публикации, и использовать один и тот же идентификатор для нескольких из них. В этом случае пакет PUBLISH будет содержать несколько идентичных идентификаторов подписки.

Идентификатор подписки связан с любой подпиской, созданной или измененной в результате пакета SUBSCRIBE. Если есть идентификатор подписки, он сохраняется вместе с подпиской. Если это свойство не указано, то отсутствие подписки сохраняется вместе с подпиской.

Идентификаторы подписки являются частью состояния сеанса на сервере и возвращаются клиенту, получающему соответствующий пакет PUBLISH. Они удаляются из состояния сеанса сервера, когда сервер получает пакет UNSUBSCRIBE, когда сервер получает пакет SUBSCRIBE от клиента для того же фильтра топиков, но с другим идентификатором подписки или без идентификатора подписки, или когда сервер отправляет Session Present равным 0 в пакете CONNACK.


Session Expiry Interval интервал истечения сеанса


Число, представляющее интервал истечения сеанса (в секундах).

Если интервал истечения сеанса отсутствует, используется значение 0. Если он установлен в 0 или отсутствует, сеанс заканчивается, когда сетевое соединение закрыто.

Если интервал истечения сеанса равен 0xFFFFFFFF (UINT_MAX), сеанс не истекает.

Клиент и сервер должны хранить состояние сеанса после закрытия сетевого соединения, если интервал истечения сеанса больше 0.

Клиент может подключаться к серверу через сеть, которая обеспечивает прерывистое соединение. Этот клиент может использовать короткий интервал истечения сеанса, чтобы он мог повторно подключиться, когда сеть снова станет доступной, и продолжить надежную доставку сообщений. Если клиент не успеет восстановить соединение, сообщения будут потеряны.

Установка Clean Start равной 1 и интервалом истечения сеанса 0 эквивалентна установке CleanSession равной 1 в спецификации спецификации MQTT версии 3.1.1. Установка Clean Start в 0 и отсутствие интервала истечения сеанса эквивалентна установке CleanSession в 0 в версии спецификации MQTT 3.1.1.


Assigned Client Identifier назначенный идентификатора клиента


Строка, которая является назначенным сервером идентификатором клиента. Используется, если в пакете CONNECT был использован идентификатор клиента нулевой длины.


Server Keep Alive Keep Alive сервера


Число, определяющее время Keep Alive, назначенное сервером. Если сервер возвращает Server Keep Alive в пакете CONNACK, клиент должен использовать это значение вместо значения, отправленного им в качестве Keep Alive. Если сервер не отправляет Server Keep Alive, он должен использовать значение Keep Alive, установленное клиентом в пакете CONNECT.

Основное использование Server Keep Alive для сервера проинформировать клиента о том, что он отключит клиента в случае неактивности раньше, чем наступит истечение времени Keep Alive, указанного клиентом.


Authentication Method метод аутентификации


Строка, содержащая название метода аутентификации, используемого для расширенной аутентификации.

Если метод аутентификации отсутствует, расширенная аутентификация не выполняется.

Метод аутентификации это соглашение между клиентом и сервером о значении данных, отправляемых в данных аутентификации и любых других полях в CONNECT, а также об обменах и обработке, необходимой клиенту и серверу для завершения аутентификации. Метод аутентификации обычно представляет собой механизм SASL.


Authentication Data данные аутентификации


Двоичные данные, содержащие данные аутентификации. Отправляются только если указан метод аутентификации. Содержимое этих данных определяется методом аутентификации.


Request Problem Information информация о проблеме запроса


Клиент использует это значение, чтобы указать, отправляется ли строка причины или пользовательские свойства в случае сбоев.

  • 0 сервер может вернуть строку причины или пользовательские свойства в пакете CONNACK или DISCONNECT, но не должен отправлять строку причины или пользовательские свойства в любом пакете, кроме PUBLISH, CONNACK или DISCONNECT,
  • 1 сервер может вернуть строку причины или пользовательские свойства для любого пакета, где это разрешено.


Will Delay Interval интервал задержки Will Message


Число, представляющее интервал задержки Will Message (в секундах). Если интервал задержки отсутствует, значение по умолчанию равно 0 и перед публикацией Will Message задержки нет.

Сервер задерживает публикацию сообщения до тех пор, пока не истечет интервал задержки или не завершится сеанс, в зависимости от того, что произойдет раньше. Если новое сетевое соединение с этим сеансом установлено до того, как истечет интервал задержки, сервер не должен отправлять Will Message.

Одним из способов использования этого является предотвращение публикации Will Message, если существует временное отключение от сети и клиенту удается повторно подключиться и продолжить сеанс до публикации сообщения.


Request Response Information запрос информации для ответа


Байт со значением 0 или 1. Клиент использует это значение, чтобы запросить у сервера информацию ответа в CONNACK.

  • 0 сервер не должен возвращать информацию ответа,
  • 1 сервер может вернуть информацию ответа в пакете CONNACK, но это не обязательно, даже если клиент запросил эту информацию.


Response Information информация для ответа


Строка UTF-8, которая используется в качестве базы для создания Response Topic. Способ, которым клиент создает Response Topic из информации ответа, не определен этой спецификацией.

Обычно это используется для передачи уникальной в глобальном масштабе части топиков, которая зарезервирована для этого клиента, по крайней мере, на время жизни его сеанса. Использование этого механизма позволяет выполнить эту настройку один раз на сервере, а не на каждом клиенте.


Server Reference ссылка на сервер


Строка, которая может использоваться клиентом для идентификации другого используемого сервера. Значение этой строки представляет собой список ссылок, разделенных пробелами. Формат ссылок не регламентирован.

Сервер может запросить, чтобы клиент использовал другой сервер, отправив CONNACK или DISCONNECT с кодом причины Использовать другой сервер или Сервер перемещен. При отправке одного из этих кодов, сервер может также включать свойство ссылки на сервер, чтобы указать местоположение сервера или серверов, которые клиент должен использовать.
  • Использовать другой сервер клиент должен временно переключиться на использование другого сервера.
  • Сервер перемещен клиент должен всегда подключаться к другому серверу.


Рекомендуется, чтобы каждая ссылка состояла из имени, за которым следуют двоеточие и номер порта. Если имя содержит двоеточие, строка имени может быть заключена в квадратные скобки. Имя, заключенное в квадратные скобки, не может содержать символ правой квадратной скобки (]). Это используется для представления адреса IPv6, который использует в качестве разделителя двоеточия.

Имя в ссылке на сервер обычно представляет собой имя хоста, DNS-имя, SRV-имя или IP-адрес. Значение после двоеточия обычно представляет собой номер порта в десятичном виде. Это не требуется, если информация о порте берется из имени (например, для SRV) или используется по умолчанию.

Если дано несколько ссылок, ожидается, что клиент выберет одну из них.

Примеры
myserver.xyz.org
myserver.xyz.org:8883
10.10.151.22:8883 [fe80::9610:3eff:fe1c]:1883


Reason String строка причины


Строка, описывающая причину, связанную с этим ответом. Сервер использует это значение для предоставления дополнительной информации клиенту.

Правильное использование строки причины в клиенте будет включать использование этой информации в исключении, генерируемом кодом клиента, или запись этой строки в журнал.


Receive Maximum максимальное значение количества пакетов QOS>0


Число, устанавливающее квоту отправки, которая используется для ограничения количества пакетов PUBLISH QOS> 0, которые могут быть отправлены без получения PUBACK (для QoS 1) или PUBCOMP (для QoS 2). То есть это значение используется для ограничения количества публикаций QoS 1 и QoS 2, отправляемых одновременно. Клиент/сервер не должны отправлять сообщения с QoS 1 и QoS 2, если есть отправленные сообщения количества Receive Maximum, на которые еще не получены ответы. При достижении Receive Maximum отправку пакетов с QoS 0 также можно приостановить, но не обязательно. При этом задерживать отправку пакетов, отличных от PUBLISH, не требуется.

Если и клиент, и сервер установили Receive Maximum равным 1, они удостоверяются, что не будет более одного сообщения в полете одновременно.

Указанное значение применяется только к текущему сетевому соединению и инициализируется повторно при переподключении.

Если значение не указано, то по умолчанию оно равно 65 535.


Topic Alias Maximum максимальное значение псевдонима топика


Число, представляющее максимальное значение псевдонима топика.

Это значение указывает самое большое значение, которое принимается в качестве псевдонима топика. Оно используется, чтобы ограничить количество псевдонимов топиков, которые необходимо хранить в этом соединении.


Topic Alias псевдоним топика


Чтобы уменьшить размер пакета PUBLISH, отправитель может использовать псевдоним топика. Это целочисленное значение, которое используется для идентификации топика вместо использования имени топика. Такой способ уменьшает размер пакета PUBLISH и полезен, когда имена топиков длинные и одни и те же имена часто используются повторно в сетевом соединении.

На стороне получателя при получении псевдонима для топика устанавливается необходимое соответствие между топиком и его псевдонимом.

Если пакет PUBLISH содержит псевдоним топика, получатель обрабатывает его следующим образом (см. п. 3.3.4 в спецификации):

  1. Если получатель уже установил сопоставление для псевдонима топика, то
    a) Если пакет имеет топик нулевой длины, получатель обрабатывает его, используя имя топика, которое соответствует псевдониму топика
    b) Если пакет содержит топик ненулевой длины, получатель обрабатывает пакет, используя это имя топика, и обновляет свое отображение для псевдонима топика на имя топика из входящего пакета.
  2. Если у получателя еще нет сопоставления для этого псевдонима, то
    a) Если пакет имеет топик нулевой длины, это ошибка протокола
    b) Если пакет содержит топик с ненулевой длиной, получатель обрабатывает пакет с использованием этого имени топика и устанавливает его сопоставления для псевдонима топика с именем топика из входящего пакета.


Maximum QoS максимальный QoS


Принимает значение 0 или 1. Если максимальное QoS отсутствует, клиент использует максимальное QoS 2.

Если сервер не поддерживает пакеты PUBLISH QoS 1 или QoS 2, он должен отправить максимальное QoS в пакете CONNACK, указав самое высокое QoS, которое он поддерживает.

Если Клиент получает максимальное QoS от Сервера, он не должен отправлять пакеты PUBLISH с уровнем QoS, превышающим указанный максимум.


Retain Available доступно сохранение


  • 0 сохраненные сообщения не поддерживаются,
  • 1 сохраненные сообщения поддерживаются.

Клиент, получающий значение Retain Available с сервера равное 0, не должен отправлять пакет PUBLISH с флагом RETAIN, установленным на 1.


User Property cвойство пользователя


Представляет собой строковую пару имя-значение. Это свойство, в отличие от других, может появляться несколько раз. Одно и то же имя может использоваться для нескольких свойств.

Это свойство может использоваться для предоставления дополнительной диагностической или другой информации.

Значение этих свойств не определено в спецификации, их значение и интерпретация известны только отправляющим и получающим клиентам.


Maximum Packet Size максимальный размер пакета


Число, определяющее максимальный размер пакета, который клиент/сервер готов принять. Размер пакета это общее количество байтов в пакете MQTT. Это свойство используется, чтобы сообщить о том, что пакеты, превышающие это ограничение, не будут обрабатываться.

Если максимальный размер пакета отсутствует, ограничение размера пакета не накладывается.

Приложение несет ответственность за выбор подходящего значения максимального размера пакета, если оно решает ограничить размер пакета.


Wildcard Subscription Available доступна подписка с подстановочными знаками


  • 0 подписки с подстановочными знаками не поддерживаются,
  • 1 такие подписки поддерживаются.

Если свойство отсутствует, то подписки с подстановочными знаками поддерживаются.

Если сервер поддерживает подписки с подстановочными знаками, он все равно может отклонить определенный запрос на подписку, содержащий подписку с подстановочными знаками.


Subscription Identifier Available доступен идентификатор подписки


  • 0 идентификаторы подписки не поддерживаются,
  • 1 идентификаторы подписки поддерживаются.

Если свойство отсутствует, то идентификаторы подписки поддерживаются.


Shared Subscription Available доступна общая подписка


  • 0 общие подписки не поддерживаются,
  • 1 общие подписки поддерживаются.

Если свойство отсутствует, то общие подписки поддерживаются.

Заключение


Напомню, что статья родилась при работе над встраиванием появившейся функциональности, описанной выше, в сервис платформы Интернета вещей. Также мне показалось, что довольно удобно вывести отображение полученных от клиента свойств в интерфейс объекта (подробнее про объекты можно почитать тут >>>). Можно скрывать неинтересные свойства, можно добавлять отображение дополнительных пользовательских свойств. В общем виде это выглядит так.




Вот, пожалуй, и всё. Для тестирования функциональности мне показался довольно удобным и наглядным вот этот проект redboltz/mqtt_cpp.

Буду очень рада, если в комментариях вы поделитесь другими open-source проектами MQTT-клиентов (как с GUI, так и без него), поддерживающих версию 5.0.
Подробнее..

Перевод Протоколы, а не Платформы технологический подход к свободе слова Часть 1

18.11.2020 10:21:27 | Автор: admin

Продвижение свободы слова за счет изменения экономической и цифровой инфраструктуры интернета

Будущее свободы слова

Серия статей, для переосмысления Первой поправки в эпоху цифровых технологий

Последние десять лет общество согласилось с пользой Интернета и социальных сетей, в попытке расширить возможности высказывания и улучшения рынка идей, но в последнее время эта точка зрения резко изменилась и теперь, кажется, что довольны далеко не все. Одни считают, что платформы наполнились троллингом, фанатизмом и ненавистью.1 Другие считают, что они стали слишком навязчивы в плане политики, и систематически замалчивают или подвергают цензуре определенные точки зрения. 2 Не говоря уже о конфиденциальности и о том, что они делают (или не делают) со всеми данными, которые они собирают.

Ситуация создала нечто вроде кризиса, как внутри, так и за пределами этих компаний. Платформы постоянно пытаются выполнять новые обязанности в качестве арбитров правды и доброты в интернете, несмотря на то, что исторически позиционируют себя защитниками свободы слова. Между тем, в США, политики из двух основных партий критикуют их, пусть даже и по совершенно разным причинам. Одни жалуются на то, что платформы потенциально допускают иностранное вмешательство в их выборы.3 Другие жалуются на то, что их использовали для распространения дезинформации и пропаганды.4 Третьи обвиняют платформы в том, что они просто слишком влиятельны.5 Следующие обращают внимание на неуместные аккаунты и удаление контента,6 в то время как другие рассуждают о попытках смягчения дискриминации по отношению к определенным политическим точкам зрения.7

Понятно, что простого разрешения у этих проблем нету, и большинство из предлагаемых, как правило, далеки от реальности технических и социальных сложностей, которые, вероятно, делают их решение невозможным.

Одни выступают за более строгое регулирование контента в интернете, в то время как такие компании, как Facebook, YouTube и Twitter, подумывают о найме тысяч сотрудников для своих команд модераторов.8 Одновременно продолжая инвестировать в искусственный интеллект для выявления спорного контента на ранней стадии процесса.9 Другие утверждают, что нужно изменить раздел 230 CDA, который дает платформам свободу действий в модерировании (или не модерировании) контента.10 Третьи предлагают вообще не допускать модерирования по крайней мере, для платформ определенного размера,чтобы они считались частью всеобщего доступа.11

Как вы увидите в этой статье, большинство из этих решений не просто сложно осуществимы, но и потенциально могут ухудшить первоначальные проблемы или даже привести к более пагубным последствиям.

В этой статье предлагается совершенно иной подход, который может показаться нелогичным, но, предлагает рабочий план, обеспечивающий улучшение ситуации со свободой слова, минимизируя влияние троллинга, языка ненависти и массовую дезинформации. Вдобавок, это поможет пользователям данных платформ восстановить контроль над своими данными. При этом создавая совершенно новые формы доходов для этих платформ.

Этот подход: строить протоколы, а не платформы.

Это подход, который вернет нас к интернету, каким он был раньше. Он включал в себя множество различных протоколовинструкций и стандартов, которые каждый мог использовать для создания совместимых интерфейсов. Электронная почта использует SMTP (Simple Mail Transfer Protocol). Чат был сделан через IRC (Internet Relay Chat). Пользовательская сеть осуществляла функции распределенной дискуссионной системы, использующей NNTP (Network News Transfer Protocol). Сама Всемирная паутина имела свой собственный протокол: протокол передачи гипертекста, или HTTP.

Однако за последние несколько десятилетий интернет вырос не столько на создании новых протоколов, сколько на контролируемых платформах, находящихся в частной собственности. Они могут функционировать идентично более ранним протоколам, но управляются только одной структурой. Произошло это по множеству причин. Очевидно, что один субъект, контролирующий платформу, может извлечь из нее прибыль. Кроме того, наличие единого подразделения может означать, что новые функции, обновления, исправления ошибок и тому подобное могут быть реализованы гораздо быстрее, что способствует увеличению количества пользователей.

Действительно, некоторые из платформ сегодня используют существующие открытые протоколы, построив вокруг них стены и захватив пользователей, а не просто предоставив интерфейс.12 Это подчеркивает, что речь идет не о выборе между платформами и протоколами, а скорее их спектр. Это говорит о том, что нам нужно двигаться в мир открытых протоколов.

Мир, где доминируют протоколы, а не проприетарные платформы, решит много проблем, с которыми сталкивается интернет. Вместо того, чтобы полагаться на несколько гигантских платформ модерирующих высказывания в интернете, может возникнуть масштабная конкуренция, в которой каждый сможет создавать свои собственные интерфейсы, фильтры и дополнительные сервисы, не прибегая к открытой цензуре для определенных высказываний. Это позволило бы конечным пользователям выбирать свой уровень толерантности для разных видов высказываний никого при этом не заставляя молчать, забрав при этом у платформ право на модерирование.

Вкратце, это подтолкнуло бы власть и принятие решений на конечных пользователей, вместо удержания ее централизованно среди небольшой группы мощных компаний.

В то же время это, скорее всего, приведет к появлению новых, более инновационных функций и более эффективному контролю со стороны конечных пользователей над своими собственными данными. Это может помочь создать ряд новых бизнес-моделей, которые будут фокусироваться не только на монетизации пользовательских данных.

Исторически сложилось, что интернет все больше и больше перемещался в мир централизованных платформ, а не децентрализованных протоколов, отчасти из-за структуры стимулов в рамках старого интернета. Протоколы было трудно монетизировать и это создавало трудности для постоянного обновления и разработки новых функций. Компании часто приходили и брали верх, создавая более централизованную платформу, добавляя свои собственные функции (и включая свои собственные бизнес-модели). Они смогли направить больше ресурсов на эти платформы (и бизнес-модели), создав эффективный цикл (и некоторое количество завоеванных пользователей) для них.

Однако это принесло свои трудности. С установлением контроля, появилась и ответственность, которая повлекла более строгий контроль контента, размещенного на этих платформах. Фильтрование и предвзятость начали перерастать в обеспокоенность пользователей.13 И вдобавок, это закончилось доминированием нескольких интернет-компаний, что (вполне обоснованно) вызывает дискомфорт у многих.14

Возвращение к фокусу на протоколах, а не платформах, может решить многие проблемы. Недавние события показывают, что это могло бы исправить многие из предыдущих ошибок протокольных систем, потенциально собрав лучшее из полученного опыта: полезные интернет-услуги, с конкуренцией, стимулирующей инновации, контролируемые не только гигантскими корпорациями, при этом финансово устойчивые и предоставляющие конечным пользователям больший контроль над своими данными и конфиденциальностьюи при этом предоставляя дезинформации гораздо меньше возможностей сеять панику.

Ранние проблемы протоколов и качественные платформы

На раннем этапе развития интернета доминировало несколько протоколов, но их ограниченность позволила платформам заполучить влияние. Существует множество различных платформ которые были успешны в течение некоторого времени и провалились (или нет), и, чтобы продемонстрировать это, мы возьмем Usenet и Reddit для сравнения.

Чисто теоретически, и Usenet, и Reddit очень похожи. В обоих случаях речь идет о форумах, организованных по определенной теме. В Usenet они назывались группами новостей. На Reddit - сабреддитами.15 Каждая новостная группа или сабреддит, как правило, имеют модераторов, уполномоченных устанавливать различные правила. Пользователи могут размещать новые сообщения в рамках каждой группы, что ведет к threads с другими участниками группы и развитию дискуссии.

Тем не менее, Usenet был открытым протоколом (технически, протоколом передачи сетевых новостей или NNTP), к которому мог подключиться любой желающий, используя различные приложения. Reddit - централизованная платформа, полностью контролируемая одной компанией.

Для получения доступа к Usenet, первоначально нужно было специальное клиентское приложение для чтения новостей (их было несколько), а затем нужно было получить доступ к серверу Usenet. Многие интернет-провайдеры сначала предлагали свои собственные услуги (когда я впервые попал в интернет в 1993 году, я использовал Usenet через сервер новостей в моем университете, а также Usenet reader, предоставленный университетом). С популяризацией интернета, все больше организаций пытались создать веб-интерфейс для Usenet. Изначально доминировала служба Deja News Research Service, предоставившая один из первых веб-интерфейсов для Usenet; позже они добавили ряд дополнительных функций, включая (наиболее полезную) всеобъемлющую поисковую систему.

Пока DejaNews экспериментировали с различными бизнес-моделями, их поисковик закрылся. Google купил их в 200116 году, вместе с архивами Usenet, которые стали ключевой частью Google Groups.

С большего Usenet была сложной и непонятной (особенно до массового появления веб - интерфейсов). Ранняя шутка на Usenet заключалась в том, что каждый сентябрь приходили смущенные новички, первокурсники колледжа, которые получали новые учетные записи и не имели никакого представления о правилах поведения и этикете на форуме. В сентябре старшекурсникам приходилось заниматься поведением новичков пока они не соответствовали стандартам форума.

А период после сентября 1993 года запомнился поклонниками старой школы Usenet как Сентябрь, который никогда не закончился или Вечный сентябрь. Это был момент когда проприетарная платформа America Online (AOL) запустила Usenet у себя, и пришло огромное количество пользователей которых было не так легко приручить.17

Контент размещался не централизованно, а между различными серверами, поскольку серверов Usenet было очень много. У этого есть свои преимущества и недостатки, в том числе то, что разные серверы могут обрабатывать разный контент по-разному. Не каждый сервер Usenet должен хостить каждую группу, что означает, что нет централизованной власти, которая бы могла заниматься модерированием деструктивного поведения или троллинга. Однако некоторые серверы могут блокировать определенные группы новостей, и пользователи могут использовать такие инструменты, как kill files, для фильтрации нежелательного контента на основе критериев, выбранных ими самими.18

Другим серьезным недостатком первоначального Usenet было то, что он был не очень гибким и адаптивным, особенно когда доходило до широкомасштабных обновлений. В децентрализованном наборе протоколов для достижения консенсуса требуется согласие многих сторон, перед тем как какое либо изменение будет внесено в протокол. Даже маленькие изменения были очень трудоемкими и не всегда признавались на глобальном уровне . Создание новой группы новостей было довольно сложным процессом. Для некоторых иерархий существовал сложный процесс согласования, но другие alt категории настраивались намного проще (хотя это не гарантировало что все серверы Usenet несли эту плату).19 Для сравнения, легко создать новый сабреддит. У Reddit есть команда разработчиков и инженеров, которые могут вносить любые изменения, в то время как у пользователей особо не спрашивают.

Возможно, самой большой проблемой старой системы было отсутствие очевидной бизнес-модели. Как показало падение Deja News, запуск сервера Usenet никогда не был особенно выгодным. Со временем наблюдался рост профессиональных серверов Usenet, которые требовали оплаты за доступ, но они появились гораздо позже, и были не настолько велики как, например, Reddit, и обычно фокусировались на торговле пиратским контентом.20

Нынешние проблемы больших платформ

В последние два десятилетия рост интернет платформFacebook, Twitter, YouTube, Reddit и других - можно сказать сместил ранее использовавшиеся протокольные системы. Платформы представляют собой единую (обычно коммерческую) компанию, которая предоставляет услуги конечным пользователям. Эти услуги обычно финансируются сначала венчурным капиталом, а затем за счёт рекламы (часто целевой).

Все платформы построены на всемирной паутине, и доступ к ним осуществляется через веб-браузер или мобильные приложения. Преимущества построения сервиса как платформы довольно очевидны: владелец имеет полный контроль над этой платформой и, таким образом, имеет гораздо больше возможностей для монетизации в том числе и с помощью рекламы (или других вспомогательных услуг). Это стимулирует платформы получать все большее количество данных от своих пользователей, чтобы лучше их таргетить.

Это привело к обоснованным опасениям и возражениям со стороны пользователей и регулирующих органов, обеспокоенных тем, что платформы играют нечестно и не особо защищают данные которые собирают со своих пользователей.21

Вторая проблема, с которой сегодня сталкиваются крупнейшие платформы, заключается в том, что их операторы все больше обеспокоены содержанием разрешенного контента, а также ответственностью, которую они несут за контроль или блокировку данного контента.22 Они столкнулись с растущим давлением со стороны пользователей и политиков, требующих от них более активной работы.23 Были приняты законы, которые более четко требуют от платформ удалять определенный контент, постепенно снижают прежнюю неприкосновенность (например, Акт о соблюдении приличий в СМИ, раздел 230, в США, или Директива об электронной торговле в ЕС), которой многие платформы наслаждались ранее при выборе уровня модерирования.

В связи с этим, было решено подтолкнуть платформы не только действовать более инициативно, но и свидетельствовать перед различными законодательными органами, чтобы нанять тысячи сотрудников для модерирования контента и инвестировать в технологии для модерирования. Тем не менее, все еще непонятно, может ли какая-нибудь платформа действительно делать "хорошую" работу по модерированию контента.

Отчасти проблема в том, что любое решение о модерации платформы кого-то да и расстроит. Очевидно, что те, чей контент был модерирован, как правило, недовольны, и то же самое можно сказать о тех, кто хотел бы увидеть или поделиться этим контентом. С другой стороны, решение не модерировать контент также может огорчить людей. Сейчас платформы часто критикуют за их виды модерации, включая обвинения (в основном без доказательств) в том, что политическая предвзятость влияет на выбор модерации контента. Поскольку платформы вынуждены брать на себя больше ответственности, каждый сделанный ими выбор в отношении модерации контента ставит их в тупик. Удалите спорный контент - и рассердите тех, кто его создал или поддерживает; воздержитесь от удаления спорного контента - разозлите тех, кто считает его неприемлемым.

Это ставит платформы в безвыходное положение. Они могут продолжать выделять все больше и больше денег на решение этой проблемы и продолжать говорить с общественностью и политиками, но непонятно, закончится ли это тогда, когда достаточное количество людей будет "удовлетворено". Не трудно найти людей, которые недовольны Facebook, Twitter и Youtube, когда они не удаляют определенный контент и тех, кто недоволен платформами, когда они в конце концов удаляют этот контент.

Эта установка расстраивает всех участников, и вряд ли в ближайшее время изменится к лучшему.

Вместо заключения

Мнения, выраженные в этой статье, являются мнениями Mike Masnick, цитируемого выше, и не обязательно соответствуют мнениям NEAR.

NEAR это блокчейн протокол и платформа для разработки децентрализованных приложений с акцентом на простоту разработки, и простоту использования для конечных пользователей.

Код NEAR открыт, наша реализация написана на Rust, её можно найтитут.

Если у вас есть идеи сервисов, управляемых сообществом, и вы хотите над ними работать, приходите в нашупрограмму поддержки предпринимателей.

Если вы разработчик, присоединяйтесь кэкосистеме.

Подробнее..

Перевод Протоколы, а не Платформы технологический подход к свободе слова Часть 2

17.12.2020 10:10:32 | Автор: admin

Протоколы спешат на помощь

В первой половине этой статьи я предлагаю вернуться в мир, где протоколы, а не платформы доминируют в Интернете. Есть основания полагать, что система протоколов может решить много проблем, вызванных платформами, но это может быть сделано за счет минимизации проблем, присущих протоколам несколько десятилетий назад.

Пока нет универсального решения проблемы, система протоколов могла бы служить для более эффективной защиты как конфиденциальности пользователей, так и свободы слова. Для этого нужно свести к минимуму последствия оскорбительного поведения в сети и создавать новые убедительные бизнес-модели, соответствующие интересам пользователей.

Залог успеха этой работы заключается в том, что появится много конкурирующих интерфейсов на протоколах для различных типов платформ, которые мы видим сегодня. Конкуренция возникнет за счет огромного выбора интерфейсов. Снижение расходов на переход от одной реализации к другой устранит замкнутость платформы, а возможность создания собственного интерфейса каждому пользователю и получение доступа ко всему содержимому по основному протоколу препятствует созданию конкуренции. Если у вас уже есть доступ ко всем, кто использует протокол социальной сети, то вам не нужно создавать новый Facebook, а просто нужно обеспечить ему другой или улучшенный интерфейс.

Пример этого уже можно увидеть в пространстве электронной почты. Существует множество различных реализаций электронной почты, основанной на открытых стандартах, таких как SMTP, POP3 и IMAP24. Популярные системы имейла в 1980-х и 1990-х годах опирались на настройки клиент-сервера, в которых провайдер услуг (будь то коммерческий провайдер интернет-услуг, университет или работодатель) размещал электронную почту только на короткий промежуток времени на сервере, пока она не была загружена на собственный компьютер пользователя через клиентское программное обеспечение, такое как Microsoft Outlook, Eudora или Thunderbird. Или пользователи могли получить доступ к электронной почте через текстовый интерфейс, например, Pine или Elm25.

В конце 1990-х годов наблюдался рост интернет-почты, начался с Rocketmail (приобретенный Yahoo, ставший Yahoo Mail) и Hotmail (приобретённый Microsoft, через несколько лет ставший Outlook.com). Google представил Gmail в 2004 году, положивший начало новому этапу инноваций, так как было предоставлено значительно больше места для хранения электронной почты, а также более быстрый пользовательский интерфейс26.

И при этом открытые стандарты предлагают большую гибкость. Пользователь может использовать адрес электронной почты, отличный от Gmail, в интерфейсе Gmail. Или он может использовать учетную запись Gmail с совершенно другим клиентом, таким как Microsoft Outlook или Apple Mail27. Кроме того, можно создавать новые интерфейсы поверх самого Gmail, например, с расширением Chrome28.

Такая гибкость имеет много преимуществ для конечного пользователя. Даже если одна платформа, подобная Gmail, становится более популярной на рынке, стоимость переключения значительно ниже. Если пользователю не нравится, как Gmail обрабатывает определенные функции или он беспокоится о политике конфиденциальности Google, переключение на другую платформу намного проще, и пользователь не теряет доступа ко всем своим старым контактам или возможности написать кому-то еще (даже тем контактам, которые остаются пользователями Gmail).

Обратите внимание, что эта гибкость служит сильным стимулом со стороны Google для убеждения, что Gmail хорошо относится к своим пользователям; Google с меньшей вероятностью предпримет действия, которые могут привести к быстрому исходу. Это отличается от полностью проприетарной платформы, такой как Facebook или Twitter, где выход из этих платформ означает, что вы больше не общаетесь с людьми таким путем и не можете легко получить доступ к их контенту и коммуникациям. С такой системой, как Gmail, легко экспортировать контакты, архивные электронные письма и переключиться на любой сервис, не теряя возможности оставаться на связи с кем угодно.

Кроме того, это создает более благоприятные условия для конкуренции. Несмотря на то, что Gmail является особенно популярным почтовым сервисом, другие смогут строить крупные почтовые сервисы, такие как Outlook.com или Yahoo Mail, или запускать успешные стартапы имейл-сервисов, ориентированные на различные рынки и ниши, типа Zohomail или Protonmail29. Также, это создает другие сервисы, строящиеся поверх существующей экосистемы электронной почты, с меньшим опасением зависеть от одной платформы, которая может закрыть их. Например, и Twitter30, и Facebook31 имеют тенденцию менять направление продукта и отключать сторонние приложения, но в сфере электронной почты существует развивающийся рынок услуг и компаний, таких как Boomerang, SaneBox и MixMax, каждая из которых предоставляет дополнительные сервисы, которые могут работать на множестве различных почтовых платформ32.

Конечным результатом является усиление конкуренции за улучшение сервиса как между службами электронной почты, так и внутри них, а также сильные стимулы для того, чтобы основные провайдеры услуг действовали в интересах своих пользователей, поскольку более низкая степень блокировки дает этим пользователям возможность уйти.

Защита свободы слова и ограничение воздействия оскорбительного поведения

Возможно, самая противоречивая часть дискуссий о модерации контента - это вопрос, что делать с оскорбительным поведением. Практически все согласны, что такое поведение существует в Интернете и может причинять вред, но нет общего мнения, что именно оно включает. Поведение, тревожащее людей, можно разделить на различные категории: преследование, воинственная риторика, угрозы, троллинг, непристойности, незаконное распространение личных данных в интернете (доксинг), спам и т. д. Но ни у одной из этих категорий нет общего определения, и большая часть этого поведения происходит на глазах пользователей. Например, попытка одного человека выразить свое мнение может быть расценена получателем как оскорбление. Ни одна из сторон не может быть ошибочной сама по себе, но предоставить каждой платформе право решать такие вещи - невыполнимая задача, особенно когда речь идет о сотнях миллионов единиц контента в день.

На сегодняшний день, платформы являются конечной централизованной властью в решении этих вопросов. Многие решили проблему с помощью все более сложных сводов внутренних не очевидных для конечных пользователей законов, передаваемых большому количеству сотрудников (часто переданных на аутсорсинг людям с относительно низкой заработной платой), которым дано очень мало времени для принятия решений по тысячам материалов33.

В такой системе ошибки Типа I (ложноположительный) и Типа II (ложноотрицательный) встречаются не просто часто; они неизбежны. Контент, который, по мнению многих, должен быть удален, остается наверху34, в то время как контент, который, по мнению других, должен оставаться наверху, удаляется35. Несколько сотрудников, занимающихся модерацией контента, могут рассматривать контент совершенно по-разному, и модераторы контента практически не могут принять во внимание контекст (отчасти потому, что большая часть контекста может быть недоступна или очевидна для них, а отчасти потому, что время, необходимое для полностью исследовать каждую ситуацию делает невозможным рентабельность). Точно так же ни одно технологическое решение не может должным образом учитывать контекст или намерение - компьютер не может распознавать такие вещи, как сатира или гипербола, даже на уровне, очевидном для любого читающего человека.

Однако протокольная система переносит большую часть процесса принятия решений из централизации на конечных пользователей. Вместо того, чтобы полагаться на единую централизованную платформу со всеми вытекающими из этого внутренними предубеждениями и стимулами, каждый мог бы создать свой набор правил, включая то, какой контент он не хочет видеть и какой контент он хотел бы продвигать. Поскольку большинство людей не захотят вручную контролировать свои предпочтения и уровни, это может легко упасть на любое число третьих лиц - будь то конкурирующие платформы, организации, представляющие общественный интерес, или местные сообщества. Эти третьи стороны могут создавать любые интерфейсы с любыми правилами.

Например, те, кто интересуется вопросами гражданских прав, могут подписаться на фильтры модерации или даже на дополнительные услуги, выпущенные ACLU или EFF. Кто-то, интересующийся политикой, может выбрать фильтр из назначенной им политической партии (хотя это, очевидно, вызывает некоторые опасения по поводу увеличения пузырей фильтров, есть основания полагать, что влияние таких вещей будет ограниченным, как мы увидим далее).

Могут появиться абсолютно новые третьи лица, полностью сосредоточенные на обеспечении лучшего опыта. Они должны касаться не только фильтра сдерживания контента, но и всего опыта пользователей. Представьте себе интерфейс, конкурирующий с Twitter, предварительно настроенный (и постоянно обновляемый) на модерацию контента из троллинговых аккаунтов и на более эффективное продвижение содержательных, заставляющих задуматься историй, а не привычных приемов кликбейта. Или интерфейс, который мог бы обеспечить лучший формат для разговоров, или для чтения новостей.

Важно сделать эту систему правил общедоступной, прозрачной и контролируемой любым конечным пользователем. Я хотел бы иметь возможность выбрать использование общедоступных элементов управления EFF для Twitter, используя интерфейс, предоставленный новой некоммерческой организацией, но затем перенастроить параметры, если я предпочитаю, скажем, больше контента о ЕС. Или, если я хочу использовать сеть в основном для чтения новостей, я могу использовать интерфейс, предоставленный New York Times. Или, если я хочу пообщаться с друзьями, я мог бы использовать специальный интерфейс, предназначенный для лучшего общения между небольшими группами друзей.

В таком мире мы можем позволить миллиону систем модерации контента придерживаться одного и того же свода правил публикаций, где каждая использует совершенно разный подход, и посмотреть, какие из них работают лучше всего. Централизованные платформы больше не являются единственным арбитром в отношении того, что разрешено, а что нет. Скорее, многие люди и организации смогут настроить систему под свой уровень комфорта и поделиться с другими - а также, позволить конкуренции происходить на уровне реализации, а не на базовом уровне социальной сети.

Это не помешает любому человеку использовать платформу как трибуну для своих выступлений, но если популярные интерфейсы и фильтры модерации контента добровольно их исключат, то это сильно ограничит силу и влияние такого выступления. Такой подход также является более демократичным, при ведь фильтры будут конкурировать на свободном рынке. Если люди считают, что один из таких интерфейсов или фильтр-провайдеров не справляется с работой, они могут перейти к другому или самостоятельно задать свои настройки.

Таким образом, у нас меньше централизованного контроля, меньше причин заявлять о цензуре, больше конкуренции, больше разнообразия подходов и больше контроля, предоставляемого конечным пользователям - все это, вероятно, сводит к минимуму охват и влияние контента, который считается оскорбительным. Действительно, наличие разнообразных фильтров, вероятно, будет определять область охвата любого человека пропорционально тому, насколько его речь будет восприниматься как нежелательная по мнению многих других.

В качестве примера можно привести споры, возникшие по поводу того, как платформы обрабатывали аккаунт Алекса Джонса, это шоу-мен, ведущий InfoWars и регулярно поддерживающий различные теории заговора. Пользователи оказали огромное давление на платформы, с целью заблокировать его, и когда они этого добились, столкнулись с аналогичным несогласием его сторонников, заявивших, что они хотят удалить Джонса только из-за предвзятого отношения к его политике36.

В системе, основанной на протоколах, приверженцы мнений о том, что Алекс не был честной личностью, вероятно, заблокировали бы его намного раньше, в то время как другие провайдеры интерфейсов, фильтров и отдельные лица могли принять решение о вмешательстве на основании любого недопустимого действия. Самые решительные сторонники всегда сохраняли бы доступ к его высказываниям, но при этом его область деятельности стала бы ограниченной. Таким образом, тем, считает эти сообщения чепухой, перестанут их видеть, а те, кто находят в них смысл, будут по-прежнему иметь к ним доступ.

Рынок различных фильтров и интерфейсов (и возможность настроить свои собственные) позволит значительно повысить степень детализации. Конспирологов и троллей будет сложнее найти с фильтрами мейнстрима, но они не будут полностью скрыты от тех, кто хочет их просматривать. Вместо сегодняшней централизованной системы, в которой все голоса более или менее равны (или полностью запрещены), в мире, построенном на протоколе, экстремистские взгляды будут просто менее привлекательны для большинства.

Защита данных и конфиденциальности пользователей

Дополнительным преимуществом является то, что система на основе протокола практически точно повысит и конфиденциальность. При протоколах, системам типа социальных сетей не нужно будет собирать и размещать все ваши данные. Вместо этого, решения о фильтрации смогут перейти к конечным пользователям, то же самое может произойти и с хранилищем данных. Хотя это может развиваться по-разному, один довольно простой метод заключается в том, что конечные пользователи просто создают свои собственные хранилища данных с помощью приложений, находящимися под контролем самих пользователей. Поскольку маловероятно, что мы вернемся в мир, где большинство будет хранить свои данные локально (тем более, что мы все чаще делаем что-то с ряда устройств, включая компьютер, смартфон и планшет), все же имеет смысл размещать эти данные в облаке, но они будут оставаться полностью под контролем конечного пользователя.

В этом мире вы можете использовать специализированную компанию по хранению данных, которая будет размещать ваши данные в облаке в виде зашифрованного большого двоичного объекта, к которому у провайдера хранилища данных не будет доступа, но к которому вы сами сможете выборочно разрешить доступ для любых целей в любой момент. Эти данные также могут выступать в качестве вашей уникальности. Затем, если вы хотите использовать протокол, подобный Twitter, вы сможете просто открыть доступ к своей базе данных для протокола, чтобы получить доступ к необходимому. Вы сможете установить, к чему ему разрешен (и не разрешен) доступ, а также вы сможете увидеть, когда и как он получал доступ к вашим данным и что он с ними делал. Это означает, что вы сможете закрыть доступ в любое время, если кто-то будет пренебрегать нормами использования. В некоторых случаях системы могут быть спроектированы таким образом, что даже когда служба получает доступ к вашим данным, она не может их собирать, получая только агрегатор или сводную информацию в хешированной форме, что обеспечивает дополнительный уровень конфиденциальности.

Таким образом, конечные пользователи по-прежнему смогут использовать свои данные для различных инструментов социальных сетей, но вместо того, чтобы хранить эти данные в скрытых хранилищах без доступа, прозрачности и контроля, элемент управления будет перемещен полностью на конечных пользователей. Посредники заинтересованы хорошо себя вести, чтобы их не заблокировали. Конечный пользователь лучше понимает, как на самом деле используются его данные, также получает возможность подписываться на другие услуги и безопасно передавать данные от одного объекта другому (или нескольким другим), что также дает новые мощные функции.

Хотя остаются некоторые опасения, что при такой системе посредники будут по-прежнему сфокусированы на использовании всех ваших данных, остается несколько причин, почему этого может и не произойти. Во-первых, учитывая возможность использования одного и того же протокола и переключения на другого провайдера интерфейса/фильтра, любой провайдер, который стал слишком "жадным" до ваших данных, рискует оказаться без людей. Во-вторых, отделяя хранилище данных от провайдера интерфейса, конечный пользователь получает большую прозрачность. Идея заключается в том, что вы будете загружать данные в хранилище данных/облачной системе в зашифрованном формате, чтобы хостинговая сторона не имела к ним доступа. Провайдеру интерфейса нужно запросить доступ, и можно будет разрабатывать инструменты и услуги, которые позволят вам, во-первых, определить, какие платформы данных будут иметь доступ, на какой срок, по каким причинам и, во-вторых, отключить доступ, если вас не устраивает его использование.

Хотя оператор интерфейса/фильтра может злоупотребить своими привилегиями по сбору и хранению данных, для этого также есть потенциальные технические средства, в том числе разработка протокола, который, будет извлекать соответствующие данные только близкие к реальному времени из вашего хранилища данных. Если он этого не делает и у него есть доступ к вашим данным, могут появиться предупреждения о том, что ваши данные размещаются против вашего желания.

Наконец, как объясняется ниже при обсуждении бизнес-модели, у провайдеров интерфейсов будут более сильные стимулы для уважения пожеланий конечных пользователей о конфиденциальности, поскольку их деньги, скорее всего, будут напрямую зависеть от интенсивности использования, а не от монетизации данных. А нарушение соглашений с пользователями может привести к прекращению работы, что нанесет ущерб их собственным экономическим интересам.

Создание условий для расширения инновационной деятельности

Система протоколов по своей сути, скорее всего, приведет к большим инновациям в данной сфере, частично позволяя любому создать интерфейс для доступа к контенту. Такой уровень конкуренции почти наверняка приведет к различным попыткам внедрения новшеств, что улучшит все аспекты предоставления сервиса. Конкурирующие компании могут предложить лучший фильтр, лучший интерфейс, лучшие функции и многое другое.

Сейчас у нас имеется только межплатформенная конкуренция, причем в довольно ограниченном виде. Понятно, что рынок может принять несколько гигантов, поэтому пока Facebook, Twitter, YouTube, Instagram и другие борются за внимание юзеров, у них меньше стимулов улучшать их услуги.

Однако, если кто-то мог представить новый интерфейс, или новые возможности, или лучшую модерацию, то неожиданно конкуренция в рамках конкретного протокола (ранее платформы) может быстро стать ожесточенной. Различные идеи будут испробованы и отброшены, но эксперимент в условиях реального мира, скорее всего, в кратчайшие сроки покажет, как эти услуги могут стать инновационными и быстро обеспечить большую ценность. В настоящее время многие платформы предлагают API, позволяющие третьим сторонам разрабатывать новые интерфейсы, но API управляются централизованными платформами - и они могут менять их ни с того, ни сего. В самом деле, Twitter много, много раз менял свою поддержку APIs и сторонних разработчиков - но в рамках протокольной системы APIs был бы открыт, с расчетом на то, что любой человек мог бы на нем строить, и не было бы централизованной компании для блокировки разработчиков37.

Кроме того, это, вероятно, создаст совершенно новые области для инноваций, в том числе в вспомогательных услугах, таких как стороны, сосредоточенные на предоставлении более эффективных инструментов модерации контента или конкурирующих хранилищах данных, обсуждавшихся ранее, которые будут служить просто для размещения доступа к вашим зашифрованным данным, без необходимости иметь доступ к ним или выполнять какие-либо конкретные действия с ними. Эти услуги могут конкурировать по скорости и времени беспрерывной работы, а не по дополнительным функциям.

Например, в мире открытых протоколов и частных хранилищ данных возможно, что преуспевающий бизнес может развиваться в виде "агентов", взаимодействующих между вашими хранилищами данных и различными сервисами, автоматизируя определенные задачи и обеспечивая дополнительную ценность. Простой версией этого может быть агент, сосредоточенный на сканировании различных протоколов и служб для получения соответствующих новостей по конкретной теме или компании, а затем отправка уведомления вам, как только он что-нибудь найдет.

Создание новых бизнес-моделей

Одна из основных причин того, что протоколы из раннего Интернета стали терять популярность по сравнению с централизованными платформами, - это проблема бизнес-модели. Наличие собственной платформы (если она приживется) - это модель, которая приносит компаниям много денег. Однако создание и поддержание протокола было проблемой на протяжении долгого времени. Большую часть работы обычно выполняли добровольцы, а протоколы со временем остановили развитие без внимания. Например, в 2014 году было обнаружено, что OpenSSL, основной протокол безопасности, на котором держится очень большая часть Интернета, имеет серьезный недостаток безопасности, известный как Heartbleed. Примерно в это же время было отмечено, что поддержка OpenSSL практически полностью отсутствует. Над OpenSSL работала небольшая группа добровольцев и один человек, работавший полный рабочий день. Фонд, который им руководил, первоначально получал довольно скромные гранты38.

Таких историй много. Как упоминалось ранее, Deja News не смогла построить большую часть бизнеса с помощью Usenet, поэтому его продали Google. Электронная почта никогда не считалась таким источником дохода, как протокол, и обычно она включалась бесплатно в вашу учетную запись интернет-провайдера. Несколько первых компаний пытались создать веб-платформы на основе электронной почты, но два значимых таких примера были быстро куплены крупными компаниями (Rocketmail от Yahoo, Hotmail от Microsoft), чтобы включить их в более крупные продукты39. В конце концов Google запустил Gmail, и он заработал приличную сумму после запуска электронной почты на своей платформе, но это не рассматривалось как крупный источник дохода. Тем не менее успехи Google и Microsoft с Gmail и Outlook, соответственно, показывают, что крупные компании могут создавать очень успешные услуги на основе открытых протоколов. Если Google испортит Gmail или создаст сложности с этой услугой, людям не составит труда перейти на другую почтовую систему и сохранить доступ ко всем, с кем они общаются.

Мы уже обсуждали конкуренцию между различными реализациями интерфейса и фильтров, для обеспечения лучшего сервиса, но, вероятно, также будет конкуренция за бизнес-модели. Скорее всего, будут проводиться эксперименты с различными типами бизнес-моделей, включающими как сервисы хранилища данных, взимающих плату за премиальный доступ и хранение (а также за безопасность), так и сервисы, как Dropbox и Amazon Web Services. Также может существовать множество бизнес-моделей, сформированных на основе реализаций и фильтров. Могут быть предложения по подписке на премиальные услуги или функции или альтернативные формы оплаты.

И хотя есть - вполне разумные - опасения по поводу настройки контроля данных текущего рекламного рынка на сегодняшних платформах социальных сетей, есть основания полагать, что в описанном здесь мире может развиваться менее требовательная к данным рекламная модель. Опять же, когда уровень данных и конфиденциальности находится в руках конечных пользователей, активный сбор данных не будет таким успешным и полезным. Вместо этого есть возможность развития нескольких типов рекламных моделей.

Во-первых, может существовать рекламная модель, основанная на более ограниченных данных, с большим упором на сочетание намерений или на чистую рекламу бренда. Взгляните на исходную рекламную модель Google, чтобы увидеть эту возможность. Она не столько полагалась на знание всей информации о вас, сколько на знание контекста ваших поисковых запросов в конкретный момент. Или мы могли бы вернуться в мир более традиционной рекламы брендов, где рекламодатели будут искать подходящие сообщества. Например, автомобильная компания будет искать рекламу в микросообществах на платформе, у которых есть заявленный интерес к автомобилям.

В качестве альтернативы, учитывая объем контроля, который конечные пользователи будут иметь над своими данными, можно разработать бизнес-модель обратного аукциона, в соответствии с которой конечные пользователи смогут сами предлагать свои данные в обмен на доступ или сделки от определенных рекламодателей. Смысл в том, что контроль будет принадлежать конечному пользователю, а не платформе.

И, наверное, самое интересное то, что есть несколько возможностей, благодаря которым протоколы могут стать более устойчивыми. В последние несколько лет, с развитием криптовалют и токенов, теоретически стало возможным создать протокол, использующий криптовалюту или токен с определенной ценностью, при этом ценность этих элементов растет по мере роста их использования40. Простой способ взглянуть на это заключается в том, что криптовалюта, основанная на токенах, является эквивалентом капитала в компании, но вместо ценности, связанной с финансовым успехом компании, ценность криптовалютного токена связана со стоимостью общей сети.

Не вдаваясь в подробности принципа их работы, эти формы валюты имеют собственную ценность, и привязаны к протоколу, который они поддерживают. По мере того, как растет количество юзеров протокола, ценность валюты или токена увеличивается. Во многих случаях использование валюты или токена может быть необходимо для работы самого протокола - таким образом, по мере более широкого использования протокола спрос на валюту/токен увеличивается, в то время как предложение остается постоянным или увеличивается в соответствии с ранее разработанным планом роста.

Это мотивирует многих людей поддерживать и использовать протокол для увеличения стоимости соответствующей валюты. В данный момент предпринимаются попытки создать протоколы, в соответствии с которыми организация, отвечающая за протокол, сохраняет некоторый процент валюты, распределяя остальную. Теоретически, при популяризации такой системы, повышение стоимости токенов/валюты могло бы помочь профинансировать текущее обслуживание и работу протокола, что эффективно устранило бы первоначальную проблему финансирования открытых протоколов, которые помогли создать современный интернет.

Точно так же у различных разработчиков интерфейсов, фильтров или агентов могут быть способы извлечь выгоду из увеличения стоимости токенов. В результате могут возникнуть разные модели, но различным реализациям может быть предоставлена определенная доля токенов, и, поскольку они помогают сети увеличивать использование, их собственная стоимость токенов также будет увеличиваться. Действительно, распределение токенов может быть привязано к количеству пользователей в конкретном интерфейсе для создания согласованных стимулов (хотя и с некоторым механизмом, позволяющим избежать игры в систему с фальшивыми пользователями). Или, как описано выше, использование токенов может быть необходимым компонентом работы реальной архитектуры систем, точно так же, как валюта Биткойн является основным элементом работы открытого реестра блокчейнов.

Во многих отношениях такая настройка лучше согласовывает интересы пользователей службы с разработчиками протоколов и дизайнерами интерфейсов. В системе, основанной на платформе, стимулы состоят в том, чтобы либо взимать плату с пользователей напрямую (что несколько противоречит интересам платформы и пользователя), либо собирать больше их данных для рекламы. Теоретически хорошая реклама может рассматриваться как ценная для конечных пользователей, но в большинстве случаев конечные пользователи замечают, что интересы платформы и пользователей имеют тенденцию не совпадать, когда платформа собирает много данных с целью таргетинга им рекламы.

Однако в рамках токенизированной системы, движущим фактором является более широкое использование для увеличения стоимости токенов. Это, очевидно, может создать другие проблемы стимулирования - уже есть опасения по поводу того, что платформы отнимают слишком много времени, и любой сервис сталкивается с проблемами, когда становится слишком большим - но, опять же, протокол будет стимулировать конкуренцию, чтобы обеспечить лучший пользовательский интерфейс, лучшие функции и лучшую модерацию, тем самым сводя к минимуму эту проблему. Действительно, интерфейс может конкурировать, предоставляя более ограниченный опыт и продвигаясь за счет способности ограничивать информационную перегрузку.

Тем не менее, возможность согласовать стимулы самой сети с финансовой выгодой создает довольно уникальную возможность, которую многие изучают.

Что может не сработать

Ничего из этого не означает, что система на основе протоколов решит полностью все проблемы. Многое из того, что было предложено выше, является спекулятивным - и, действительно, мы уже видели, что платформы обгоняли протоколы, пока у протоколов была ограничена возможность развития.

Сложность убивает

Вполне возможно, что любая система, основанная на протоколах, будет слишком сложной и громоздкой для привлечения большой базы пользователей. Юзеры не хотят возиться с множеством настроек или приложениями, чтобы привести что-то в работу. Они просто хотят узнать, что это за услуга, и без особого труда пользоваться ею. Платформы с самого начала довольно хорошо фокусировались на аспекте взаимодействия с пользователем, особенно на привлечении новых пользователей41.

Можно было бы надеяться на попытку создать новый режим, основанный на протоколах, что он смог бы извлечь уроки из успеха современных платформ и развить их. Точно так же внутрипротокольная конкуренция на уровне обслуживания может создать большие стимулы для создания лучшего пользовательского опыта - и то же самое можно сказать о ценности связанной криптовалюты, которая буквально привязана к созданию лучшего пользовательского опыта. В самом деле, предоставление самого простого и удобного интерфейса для доступа к протоколу, вероятно, будет основной областью конкуренции.

Наконец, одна из причин, по которой платформы с самого начала опережали протоколы, заключается в том, что все, что контролируется одним объектом, также приводит к явному повышению производительности. В мире протоколов с отдельными хранилищами данных/интерфейсами вы будете больше рассчитывать на то, что несколько компаний объединятся. Интернет-гиганты, такие как Google, Facebook и Amazon, действительно усовершенствовали свою работу, взаимодействуя друг с другом, включение в эту группу нескольких сторонних производителей повысит риск. Однако в этой области были широко распространены технологические усовершенствования (и, действительно, крупные платформенные компании открыли исходный код некоторых из своих собственных технологий, которые сделали это возможным). Вдобавок ко всему, скорости широкополосного доступа увеличились и должны продолжать расти, возможно, минимизируя техническое препятствие.

Существующие платформы слишком велики и это никогда не изменятся

Еще одним потенциальным препятствием является то, что существующие платформы - Facebook, YouTube, Twitter, Reddit и тд- уже настолько велики и внедрены в повседневную жизнь, что от них практически невозможно избавиться с помощью подхода, основанного на протоколах. Эта критика предполагает, что единственный способом избавления от платформ является создание совершенно новой системы, основанной на протоколах. Это может сработать, но сами платформы также могут рассмотреть возможность использования протоколов.

Многие могут задать вопрос, зачем платформам использовать протоколы, если это будет означать избавление от монополистического контроля в их системе, которым они в настоящее время пользуются в отношении информации, и возвращение этих данных в систему под контроль конечного пользователя и использование в конкурирующих сервисах, использующих тот же протокол. Тем не менее, есть причины полагать, что некоторые платформы действительно могут пойти на этот компромисс.

Во-первых, по мере увеличения давления на платформы, им все чаще приходится осознавать, что то, что они сейчас делают, не работает и вряд ли когда-то будет работать. Нынешний режим работы только приведет к еще большему давлению с целью решить то, что кажется нерешаемой проблемой. В какой-то момент переход к системе протоколов может стать способом для существующих платформ избавиться от невыносимого груза ответственности за то, что делает каждый человек на их платформе.

Во-вторых, продолжение того, что они делают, будет обходиться все дороже. Facebook уже недавно пообещал нанять еще десять тысяч модераторов; YouTube также пообещал нанять тысячи модераторов42. Наем всех этих людей будет увеличивать расходы и для компаний. Переход на систему, основанную на протоколах, переместит элемент модерации на конечных пользователей или на конкурирующие третьи стороны, снимая эти расходы с бухгалтерских книг для крупных платформ.

В-третьих, существующие платформы могут исследовать использование протоколов как эффективный способ конкуренции с другими крупными интернет-платформами в областях, где у них гораздо меньше возможностей для конкуренции. Например, Google отказался от множества попыток создать социальную сеть в стиле Facebook43. Однако, если он по-прежнему считает, что должна быть социальная сеть, альтернативная Facebook, он может согласиться с предложением системы на основе открытых протоколов. Фактически, признание того, что компания вряд ли сможет создать собственное проприетарное решение, сделало бы предложение системы открытого протокола хорошей альтернативой, хотя бы для сокращения позиций Facebook.

И наконец, если будет показано, что подход с использованием токен/криптовалюты работает как метод поддержки успешного протокола, то, возможно, будет даже полезнее создавать эти услуги в качестве протоколов, а не в качестве централизованных контролируемых платформ

Это ухудшит проблему пузыря фильтров

Некоторые утверждали, что такой подход усугубит некоторые проблемы, связанные с оскорбительным контентом в Интернете. Основная идея в том, что позволить жестоким людям - будь то троллям или ужасающим неонацистам - иметь любую возможность высказывать свое мнение, будет проблемой. И чтобы пойти еще дальше, они будут утверждать, что, допуская использование конкурирующих услуг, вы в конечном итоге получите помойку в Интернете, где худшее из худшего будет продолжать накапливаться.

Хотя я с пониманием отношусь к этой возможности, это кажется неизбежным в силу какого- либо воображения. Один аргумент против этой жалобы состоит в том, что уже есть люди, заражающие различные социальные сети, и пока ничего не помогло избавиться от них. Но важнее то, что это, скорее всего, в какой-то степени поместит их в карантин, поскольку их контент с меньшей вероятностью попадет в наиболее используемые реализации и службы протокола. То есть, хотя они могли бы быть подлыми в своих темных уголках, способность заражать остальную часть Интернета и (что важно) искать и вербовать других будет сильно ограничена.

В какой-то степени мы уже видели это в действии. Когда их вынуждали собираться в своих уголках Интернета после исключения с таких сайтов, как Facebook и Twitter, альтернативные службы, обслуживающие исключительно этих пользователей, не были особенно успешными в расширении или росте с течением времени. Всегда найдутся люди с сумасшедшими идеями, но предоставление им собственного маленького пространства для сумасшествия может лучше защитить Интернет, чем постоянно убирать их с любой другой платформы.

Работа с более проблемным контентом

Ключевое предположение во многом состоит в том, что большая часть нежелательного контента, создающего здесь головную боль, находится в широком сером спектре, а не в черном и белом. Однако есть некоторый контент - часто контент, нарушающий различные законы - который намного понятнее и не находится в середине спектра. Есть веские причины для беспокойства по поводу того, как эта установка может позволить сообществам формироваться вокруг таких вещей, как детское порно, порно-месть, преследование, доксинг или другие виды преступной деятельности.

Конечно, реальность такова, что такого рода сообщества уже формируются - часто в даркнете - и сегодня с ними справляются в основном через правоохранительные органы (а иногда и через журналистские расследования). Кажется вполне вероятным, что то же самое будет правильным и при этой настройке. Нет оснований полагать, что в мире, ориентированном на протоколы, эта проблема будет сильно отличаться от существующей сейчас.

Кроме того, с системой открытых протоколов фактически будет большая прозрачность, и некоторые (например, группы гражданского общества, которые отслеживают группы ненависти или правоохранительные органы) смогут даже создавать и раскрывать агентов, контролирующих эти пространства и смогут запускать уведомления об особо вопиющих комментариях, требующих более пристального внимания. Кто-то, кого преследуют, вместо того, чтобы отслеживать преследователя напрямую, может использовать цифрового агента для сканирования более широкого набора протоколов, чтобы определить, есть ли какой-либо контент, который наводит на мысль, а затем напрямую предупредить полицию или другие соответствующие контакты.

Пример в действии / Как это будет выглядеть на практике

Как описано выше, это может происходить разными способами. Существующие сервисы могут обнаружить, что бремя централизованной платформы становится слишком дорогостоящим, и поэтому следует искать альтернативную модель, а подход с использованием токенизации / криптовалюты может даже сделать это осуществимым с финансовой точки зрения.

В качестве альтернативы для этого могут быть созданы новые протоколы. Уже есть ряд попыток на разных уровнях. Такие сервисы, как IPFS (межпланетная файловая система) и связанное с ним предложение Filecoin, уже закладывают основу и инфраструктуру для распределенного набора сервисов, построенных на его протоколе и валюте44. Сам изобретатель всемирной паутины Тим Бернерс-Ли работал над системой под названием Solid, которая теперь находится в его новой компании Inrupt, которая поможет сделать Интернет более распределенным45. Другие проекты, такие как Indieweb, объединяют людей для создания многих частей, которые могут внести свой вклад в будущий мир протоколов вместо платформ46.

В любом случае, если протокол будет установлен и начнет набирать обороты, мы хотим увидеть несколько ключевых вещей: несколько реализаций / сервисов на одном и том же протоколе, предоставляющие пользователям выбор, какой сервис использовать, а не ограничивая их одним. Мы также начнем видеть рост нового направления бизнеса, связанного с безопасным хранением данных, поскольку пользователи отойдут от бесплатного предоставления своих данных платформам и будут иметь больший контроль. Вероятно, что в результате этого появятся и другие новые услуги и возможности, особенно в связи с усилением конкуренции за создание лучшего набора услуг для пользователей.

Заключение

За последние полвека сетевых вычислений маятник качался между вычислениями на стороне клиента и на стороне сервера. Мы перешли от мэйнфреймов и немых терминалов к мощным настольным компьютерам, веб-приложениям и облаку. Возможно, мы начнем видеть подобный маятник и в этой сфере. Мы ушли от мира, в котором протоколы доминировали, к миру, в котором централизованные платформы все контролируют. Если вернуть нас в мир, где протоколы доминируют над платформами, это может принести огромную пользу свободе слова и инновациям в Интернете.

Такой шаг может вернуть нас к раннему замыслу Интернета: создать место, где единомышленники могут общаться на различные темы по всему миру, и каждый может найти полезную информацию по множеству разных тем, не захламляя ее, путем дезинформации. Одновременно это могло бы способствовать большей конкуренции и инновациям в Интернете, а также дать конечным пользователям больший контроль над своими данными и не дать гигантским корпорациям иметь много данных о каком-то конкретном пользователе.

Переход к протоколам, вместо платформ - это подход к свободе слова в двадцать первом веке. Вместо того, чтобы полагаться на рынок идей в рамках отдельной платформы, который может быть захвачен злоумышленниками, протоколы могут привести к созданию рынка идеалов, на котором возникнет конкуренция за предоставление более качественных услуг, минимизирующих влияние тех, кто имеет плохие намерения , не лишая их возможности говорить все, что они хотят.

Это было бы радикальным изменением, но к нему следует относиться серьезно.

От NEAR

Мнения, выраженные в этой статье, являются мнениями Mike Masnick, цитируемого выше, и не обязательно соответствуют мнениям NEAR.Мемы добавлены редактором и переводчиком статьи и не относятся к оригиналу изданному Mike Masnickю

NEAR это блокчейн протокол и платформа для разработки децентрализованных приложений с акцентом на простоту разработки, и простоту использования для конечных пользователей.

Код NEAR открыт, наша реализация написана на Rust, её можно найтитут.

Если у вас есть идеи сервисов, управляемых сообществом, и вы хотите над ними работать, приходите в нашупрограмму поддержки предпринимателей.

Если вы разработчик, присоединяйтесь кэкосистеме.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru