Ещё немного о картографии снов

[DisPetcher]

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

[Alvina]

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

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

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

Такая-же история..

[Eastwind]

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

[аметил]

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

[ioneks]

Стоит ещё обсудить вопрос приватности данных.

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

И хотя у этого подхода есть свои плюсы (простота реализации), есть и минусы — фактическая доступность данных администрации. Если заглянуть вперёд, в то будущее, когда будет сеть нод и пойнтов, то любой обладатель ноды получает доступ ко всем данным. Это, на мой взгляд, недопустимо, потому что любой может просто «слить» приватные данные в сеть.

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

Некоторые сложности возникают при открытии общего доступа к снам. Рассмотрим разные уровни общего доступа к приватным данным.

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

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

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

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

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

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

Хотелось бы услышать ваше мнение на этот счёт.

[DisPetcher]

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

[ioneks]

Диспетчер, ты о какой общей карте толкуешь? Мы ведь не раз уже обсуждали вопрос, что никакой общей карты не подразумевается, кроме, быть-может, какой-нибудь квази-карты. Если ты видишь иначе этот вопрос, про общую карту, то изложи своё видение.

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

Мой предыдущий пост — как раз о таком механизме.

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

[DisPetcher]

вопрос:
если я хочу посмотреть сны (открытые) других участников по определенному тегу (ну например, #ДомУчителей), откуда будут подтягиваться сны - где они физически находятся? у каждой ноды своя база или как? если нет централизации и синхронизации баз, то как получить всю доступную информацию?
я, возможно, туплю, но саму архитектуру не очень понимаю.

[ioneks]

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

[ioneks]

В связи с этими паролями у меня возник технический вопрос, может кто в курсе.

При входе в систему пользователь вводит пароль. Соответственно, этот пароль должен сохраниться в клиенте, но не посылаться на сервер. При обновлении страницы всё же сбросится. В куки тоже не сохранишь, потому что они отсылаются на сервер. Что тут можно сделать? У меня две идеи. Первая — использовать single page-подход, когда страница один раз загружается, а затем через AJAX обновляет свой контент, реагируя на действия юзера (показывает результаты запросов, редактирует сны, и т.п.). Вторая — использовать browser local storage. Но я не уверен насчёт переносимости этого решения. Во всех ли браузерах он есть?