Skip to content
This repository was archived by the owner on Mar 3, 2025. It is now read-only.
This repository was archived by the owner on Mar 3, 2025. It is now read-only.

Implement Location Proof Recipe using a network machine strategy #117

Description

@johnx25bd

Summary

Develop and document a location proof recipe for a network machine strategy. This approach relies on hardware devices or nodes within a network attesting to their position or presence relative to each other, such as Time of Flight (ToF), Time Difference of Arrival (TDoA), or similar techniques. The goal is to establish a clear and reusable pattern, with code and documentation, that can be attached to location proofs created based on the generalized Location Proof Protocol.

Purpose

  • Enable location proofs based on network-based device interactions (e.g., triangulation, ToF, TDoA).
  • Provide developers with a pattern and implementation for integrating this strategy into applications.
  • Extend the Location Proof Protocol’s flexibility while maintaining adherence to the standardized data model.

Requirements

0. Research Prior Art

  • Research and document existing techniques for documenting device presence based on network-based interactions (e.g., ToF, TDoA, local network triangulation).
  • See WitnessChain, Proximum for inspiration.

1. Define the network machine strategy

  • Determine how devices or network nodes will interact to generate and verify location proofs:
    • Examples: Time of Flight exchanges, triangulation, or cryptographic signatures between networked devices.
    • Consider privacy, trust, and scalability in networked environments.
  • Define the inputs and outputs for this recipe:
    • Input: Data from nodes/devices (e.g., timestamps, signal strength, signed attestations).
    • Output: Verifiable data that can be encoded in the proof schema as an element in the recipePayload bytes array.

2. Implement the Recipe

  • Implement the code required for devices to generate location proofs with this recipe data attached.
  • Implement code to verify location proofs with recipe data attached in a client or server environment.
  • (Ideally) implement a smart contract function to verify location proofs with this recipe data attached (onchain verification).

3. Documentation

  • Provide a detailed walkthrough in the repository:
    • Explain the strategy and how it works (inputs, outputs, logic).
    • Include setup instructions for testing or integrating this recipe.
    • Example proof data for developers to reference.
    • This should be submitted as a pull request to this repo (astralprotocol), in a directory here. See this for an example, untested(!) recipe. (This is far from defined, we want help refining exactly how proof recipes are documented.)

4. Testing

  • Write unit tests for the recipe, covering:
    • Successful proof creation and validation.
    • Edge cases (e.g., incorrect timestamps, network failures).
    • Performance under typical and high-load conditions.
  • Provide a simple front-end demo or CLI example for local testing.

5. Encourage Developer Creativity

  • While the base implementation can use ToF, TDoA, or local network triangulation, you can propose alternative approaches — we haven't figured this out, it's innovation work!

Acceptance Criteria

  • A description of the recipe, data collected, how it's created, plus code for creating and verifying proofs using a network machine strategy, submitted to this repository as a pull request.
  • Comprehensive tests and documentation for creating and verifying location proofs using this strategy.

Tasks

  • Design and define the strategy, including key interactions and schema mappings.
  • Implement the recipe creation + validation scripts (preferably in Typescript or Python, plus optionally a verification function in Solidity).
  • Write unit tests to validate the recipe’s functionality.
  • Add documentation with clear examples for using the recipe.
  • Create a simple demo (e.g., CLI or web-based) to showcase the strategy.
  • Submit for peer review and incorporate feedback.

If you have questions or ideas for alternative approaches, feel free to comment or raise a related issue in the repository.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions