Add `attributes` and `attributesSchema` fields to the Location Protocol

[johnx25bd]

Summary

We propose introducing an optional attributes field to the core location attestation schema, enabling developers to include structured metadata alongside spatial data. This would be paired with an optional attributesSchema field to define expected structure and types.

Motivation

Many location use cases involve rich, structured metadata:

• Field observations (species, height, health_status)
• Environmental monitoring (CO₂_ppm, sensor_model)
• Logistics (item_id, temperature_celsius)
• Social check-ins (event_id, mood, intent)

Currently, developers must attach structured metadata in the mediaData array or shoehorn it into the memo field. Introducing a first-class attributes field improves composability, verifiability, and downstream interoperability. The term attributes aligns with established GIS conventions—specifically, the "attribute table" associated with geographic features—making it a familiar and semantically clear choice.

To be most useful, we should clearly specify how attributes data should be structured and parsed — e.g., JSON-encoded key-value pairs validated against a known schema.

Alternatives to adding a top-level field include defining a convention where structured attributes are always embedded as the first element of the mediaData array (e.g., a CID pointing to a JSON object). However, this approach is more brittle and harder to validate across clients.

Proposed Fields

Field	Type	Description
attributes	string	JSON-encoded string with structured metadata, or a CID / URI resolving to this string
attributesSchema	string	Optional reference to schema — may be raw string, IPFS CID, or EAS schema UID

Schema Interpretation Options

attributesSchema could take one of the following forms:

• Raw string schema – similar to the current schemaRawString format
• IPFS CID – references a JSON Schema document
• <chainID>:<schemaUID> – references a deployed EAS schema onchain

Downstream consumers can validate or interpret attributes using the referenced schema.

Implementation Notes

• Both fields are optional; the core protocol remains minimal.
• This pattern aligns with existing recipeType / recipePayload design.
• Could be used immediately by apps like Logbook, biodiversity tools, and dMRV clients.

Open Questions

• Should we define a registry or format standard for attributesSchema URIs?
• Is it useful to enforce a minimum structure (e.g., JSON parseability) for attributes?

Would love input from anyone working on semantically rich attestations or standards-based metadata.