指定された日付より前および/または特定の地理的位置のみでデータを公開または送信するためのサービスアプローチ

こんにちは



私は、指定された日付よりも早く、および/または特定の地理的位置でのみ、出版またはデータ転送サービスの概念をあなたと話したいです。 （ 明らかなものを除く）批判や感情的なコメント（恐怖、経験、予期しないケースなど）を楽しみにしています。 まず第一に、これはアプローチですが、さらに、簡単にするために、これをサービスと呼びます。



サービスアーキテクチャの根底にあるのは、すべての仲介者に不信を抱いている、ソースデータの暗号化であり、それを可能な限り多くの部分に分割し（それ自体では意味がありません）、その後の参加者間の「分散」です。 十分な数の参加者、さまざまなオペレーティングシステム、デバイス、および管轄区域では、介入しようとする試みは無意味であるか、ローカルで適切な対策を講じるのに十分なほど顕著です。



最も厳密な設定では、「ピース」（以下、 iprates-情報パーティクル ）の返送を制御することは、デバイス自体にアーキテクチャ上、つまり「あきらめません。早すぎます」という位置にあります。







アプローチの図：





シナリオをリストする前に、わかりやすくするために、出発前のサービスへのデータの転送を制御するための可能な基準（日付、位置情報、および「全員向け」を含むメーリングリスト）に注意します。

使用シナリオ：

• 日記、「表の中」のブログ
  なんで？

  明らかに存在しない放送への参加者への関心、そして最初の要望で、編集/想起の不可能性。 何回、私たちが伝えたかった重要な何かをコピーしたり、限定したり、ドラフトや存在しないもので送ったりしました。 リボンの鶏の胸肉のレシピの数から判断すると、健全な自己批判を完全に欠いている人々がいます。 しかし、間違いなく、変更された聴衆や過度に広い聴衆、あるいは将来の自分自身によるイベントの再考の可能性を非常に頻繁に考慮するのは私だけではありません。 主要なイベント、反応、決定はそのまま記録する必要があります。 何も振り返ることなく、これは風変わりな太鼓ではないことを知っている「見ている-私は生きている」。 世代ごとに同意し、同じ感情的なレーキを踏む：何かが忘れられ、痛みを伴う結論や「保存」の試みのために、意図的に何かが回避される。 ストーリーがいかに調和していても、遺伝子、環境、開発段階は消えません。 刺激的な架空の小説や傑出した伝記を読むことは有用ですが、装飾なしで両親の発達の実話を読むことは、100倍も有用です。 説明された経験に従うか、従わないか-子供自身が新しいコンテキストに基づいてそれを理解します。 しかし、選択を与えることなく、額を同じ壁に打ち付けることは、私の意見では、いくつかの怠慢と無責任の現れです
• 特定の地理座標を使用して、指定された期間内の特定の人々へのメッセージ -意味のあるアプリケーションは、現代の方法で宝物の楽しみのためだけに発生しない
• デジタル遺書、未来への手紙など -何らかの形で既にインターネット上に表示されていますが、淡い色で表示されています。 しかし、個人の公式デジタル署名の配布は、これらすべてに新しい命を吹き込みます
• 心理的戻り止めは、あなたが抵抗せずに言いたいが、そうではないときに、あらゆる色合いの感情を最大限に匿名で認識または表現する手段です
• 組織のパソコンドライブの空き領域の使用 。 ユーザーの職場では、原則として、多くの未使用スペースがありますが、特定の各PCまたはそのグループに対する公正な不信感からは目立たなくなります。 ただし、暗号化されたアーカイブ/重要度が中程度以下のバックアップの一部は、恐れることなく散らばることができ、特定の部分のみをキーストレージシステムに残します。 ただし、暗号化ツールと同期ツールを組み合わせて、不要なシャーマニズムなしでこれを実現できます

明らかな困難とソリューションへのアプローチ：

• ユーザーのクリティカルマス 。 採用方法：ポジショニング、マーケティング、公的保証/オープンソース、「設計による」口コミ
• 「ハニーポットとその逆」という妥協的なエージェントの絶え間ない存在と、参加者の損失、ローテーション。 影響を最小限に抑える方法：
  • 信頼できない参加者の最大50％を許可する数学的分布モデル
  • 署名された推奨事項の公開チェーンを含む信頼基準の開発
  • 分散型および匿名のエントリポイント：Tor / DHT-p2pを介したアドレス転送をiprates
  • ipratesの非人格化-それぞれが隣人（左/右、またはソースデータの3次元表現の場合は上下）のみを知っている
    Thrift定義のipratesコースの例

    struct IprateSelfAwareness { 1: optional string leftIprateUuid, 2: optional Checksum leftIprateCS, 3: optional string rightIprateUuid, 4: optional Checksum rightIprateCS, 5: optional i64 position, } struct Iprate { 1: string uuid, 2: EncodedValue encodedValue, 3: optional Date creationDate, 4: optional Date publishDate, 5: optional string lastPingDate, 6: optional i32 publishIfNoPingCntMonths, 7: optional string tomeUuid, 8: optional IprateSelfAwareness selfAwareness, 9: optional auth.User owner, 10: optional IprateExtra extra }
          
          
    
            
            
            
          
    
        
            
            
            
          
          
    
            
            
            
          
    
        
         

    
    
    
• キーサーバーへの攻撃。 概念実証のアルファテストの段階でのみ意味があります。 分散配信の前提、および他の誰かが「可能な場合」にソースデータを取得する際の障害がないことにより、キーサーバーの概念が排除されます。
• 暗号技術とツールの陳腐化。 エンドデバイスの大規模なローカル制御に加えて、このリスクを平準化する方法を思いつきませんでした。 最も重要なリスクを無視できないために含める

なぜここにあるの

プロジェクト管理には動機付けと経験と経験の両方があるという事実にもかかわらず、プロジェクトはあまりにも膨大であり、発表の方法と時間、および自由時間に制限される公約に敏感です。 さらに、ある程度の審議の後、彼が聞いて理解し、需要があることが私にとってより重要です。 そして、この投稿の目的は、まず第一に、このアプローチについて話し、あなたの意見を得ることにあります。 そして興味があり、志を同じくする人々がいる場合：応用数学者、開発者、情報セキュリティ専門家、そして英語に翻訳し、ビデオを録画し、イラストとオープンバイザーリポジトリでブームまたはキックスターターに行く-時間の問題。