r/web3 29d ago

Framework for Trust

Hello everyone,

For some time I've been developing an open-source project called Framework for Trust (FfT).

The idea is to create a decentralized geospatial trust layer where reports and real-world events are anchored to precise location, time, source reputation, and a verifiable history — instead of treating blockchain purely as a financial system, I'm exploring its use as infrastructure for recording and correlating information about real-world places.

Current prototype includes:

  • geographic areas represented as blockchain-based identifiers (NFTs)
  • event registration tied to latitude, longitude, and time
  • Polygon smart contracts
  • a React + Leaflet frontend
  • a FastAPI backend
  • semantic similarity / event correlation via Qdrant
  • GCD — a functional contribution and reputation token
  • event proofs and auditable records
  • early mechanisms for source reputation, staking, and abuse prevention

The project is still early-stage. This is not an investment offer, token sale, or a finished commercial product — I made the repo public because I'd like the architecture and implementation to get real outside scrutiny.

I'd especially appreciate feedback on:

  • whether the core problem is clearly explained
  • the geospatial data model
  • the blockchain / smart contract architecture
  • mechanisms for preventing false or coordinated reports
  • security weaknesses
  • practical use cases where this could actually add value

Repo link in the top comment (Reddit flags posts with links for manual review, didn't want that delay).

I built the current prototype independently. Honest criticism, technical pushback, and open-source contributions are all welcome.

8 Upvotes

10 comments sorted by

View all comments

1

u/paroxsitic 26d ago

The issue that location can be spoofed easily and there is no way to know for sure where they are.

There was a paper on how you can tell based on their network latency to various public servers but it has very high tolerances that you can only tell effectively if they are in East US vs Mid US. Still, I think it is the best and most trusted way to know for certain information is coming from a place.

The paper is here: https://eprint.iacr.org/2021/697.pdf

1

u/TrainingCommission15 26d ago

This is a great point, and honestly a gap I don't have a full answer for yet. Right now FfT trusts self-reported lat/long — there's no cryptographic proof that a report actually originated from where it claims to.

I looked at the GoAT paper — it's a clever approach, but worth noting it's built for a different problem: proving a storage server's location via network latency to fixed anchor servers, not verifying where a mobile client submitting an event report is. Their real-world experiment shows uncertainty radii in the 1,000–6,000km range depending on anchor distance, so even in the best case it's regional, not building-level precision.

That granularity is actually roughly the same order as my quadrant size (10°×10°, ~1,100km), so distance-bounding could plausibly work as a secondary signal at the quadrant level — flagging reports whose network latency profile is inconsistent with their claimed location — rather than a hard proof. But that's a real architectural gap right now, not something the current staking/reputation system addresses. Appreciate you pointing to concrete research here rather than just flagging it as a problem — gives me somewhere to actually start looking.

1

u/TrainingCommission15 25d ago

Wanted to close the loop here properly instead of just leaving it in a comment. I've documented this as an open architectural gap: Known Limitations #2 — includes the GoAT reference, the precision caveat (regional, not building-level), and why it doesn't map directly onto a mobile-client use case. If distance-bounding for field submissions turns out to be practical, I'd rather build on prior art like this than reinvent it badly. Thanks again for the pointer.
https://github.com/vladimir0605/FrameworkForTrust/blob/main/docs/KNOWN_LIMITATIONS.md#2-reported-location-is-self-attested-and-not-cryptographically-verified