Web3-мессенджер размером в 3.5 Мб: инди-разработка с нулевым бюджетом

[Void-Cowboy]

Я уже более 10 лет слышу про Web3, революционную революцию и социальные сети на этом.

Лет пять назад, как раз накануне полномаштабки, даже участвовал краем (как бекендер) для тестового проекта где веселые и находчивые фронт-ендеры пытались родить аналог Инстраграмма на Web3.

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

Децентрализация это сетевой уровень, браузерно это не решается. Тот же Yggdrasil как "прокси" что перехватывает *.ygg адреса по типу onion в качестве костыльного решения можно назвать децентрализованной сетью. Но до реальной такой сети протоколу еще далеко (хотя и в раз ближе чем 5 лет назад).

[snuk182]

В свое время почти получилось у Skype, сервера авторизации и пачки STUN/TURN гейтов было достаточно для стабильной работы. А потом Майки за него взялись смело и превратили в го Тимс.

[pol_pot]

Разрабатывая свой мессенджер,

Зачем ты это делаешь? Существующие мессенджеры давно уже покрывают все потребности, среди людей нет запроса на еще один мессенджер.

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

[longtolik]

Вы упомянули процессор DX40, у меня был SX33 MHz. Было мнение, что 33 работал быстрее. Всё из-за частоты шины в 33 MHz. Процессор с тактовой частотой выбирал данные через 20 наносекунд, но они поставлялись через 33 наносекунды и процессору приходилось ждать ещё один цикл, то есть, ещё 20 наносекунд, всего 40 нс. В то же время 33 мегагерцовый процессор делал все за свои 33 наносекунды. Если это правда, то какой смысл в 40 MHz, кроме маркетинга, шина PCI тоже работала строго на 33 наносекундах.

А мессенджеры нужны разные. Я подумывал об IP-телефонии, но она у нас под запретом, похоже.

[slog2]

Странное у вас было мнение. Насколько я помню DX40 полноценные процы с 32-х битной шиной. SX урезанные дешёвые версии, шина 16 бит и ещё чего-то. Стоили дешевле, кушали меньше.

[longtolik]

Тут речь не о ширине шины, а частоте, на которой она работала...

[moscowman]

Doom на 386 SX-33 был в режиме слайдшоу, по сравнению с 386 DX-40.
Но если вы были владельцем 486-го DX компьютера, то тоже было верно и в отношении 386 DX-40

[d3d14]

А где его найти то? (ссылка)
И есть ли версия для браузера?

[Khronic1979]

Это не децентрализованный мессенджер. Децентрализация подразумевает отсутствие посредника в виде сервера, а даже для webrtc требуется сигнальный сервер, для установки соединения между пирами, а также во многих случаях stun или turn сервера для передачи медиа потоков. Плюс сообщения судя по всему также идут через сервер. Тут децентрализована только схема взаиморасчётов. Так что автор некорректно использует понятия, вводя в заблуждение читателей.

[tema_rebel]

Давайте не будем говорить, что крипта анонимна и что ограничительные меры к ней не применимы.

[0xInnominatus]

@alex_marshal о, вижу вы используете библиотеку Nethereum, активным контрибьютором которой я являюсь. Так как вы делаете упор на оптимизацию потребляемых ресурсов, то хотел бы дать несколько рекомендаций по использованию современного Nethereum:

1. Ваш токен сейчас использует decimals = 18, поэтому в функциях типа GetTreasuryBalance вы получаете баланс в WAD/WEI с помощью типа BigInteger, так как в ulong оно рискует не поместиться. Начиная с шестой версии я добавил поддержку декодирования балансов и других переменных в типы UInt128, что позволит корректно работать с балансами в вашем токене вплоть до 30 десятичных разрядов до запятой и ещё 18 после. Поэтому рекомендую вместо BitInteger использовать UInt128 для чтения балансов и других значений, например, вот так treasuryBalFunc.CallAsync<UInt128>(),— это позволит вам избержать алллокаций на куче и сделать приложение быстрее и без фризов, рекомендую!

2. Вместо инструкций типа web3.Eth.GetContract(treasuryBalAbi, GAMES_CONTRACT).GetFunction("treasuryBalance") рекомендую использовать кодогенерацию или же писать объявлять функции через атрибут [Function],- это более надёжный, быстрый и эффективный подход.

Вообще как вам сейчас Nethereum? Возможно хотели бы дать какой-то фидбек или нужна помощь с использованием? Или есть мысли относительно того, что бы ещё добавить/оптимизировать или на чём следует сосредоточиться при планировании дальнейшего развития? Также не стесняйтесь открывать issue/задавать вопросы на github или в Discord Nethereum!

[0xInnominatus]

Если встроенных в C# системных 128-битных типов будет всё же недостаточно, то рекомендую C# реализацию Int256 от Nethermind (нода Ethereum и ещё ряда других EVM-совместимых чейнов). Она не интегрирована напрямую в Nethereum в силу другой политики по целевым платформам, но обычно используется без каких-либо проблем.