Skip to content

Latest commit

 

History

History
139 lines (92 loc) · 4.2 KB

20240411-telco.md

File metadata and controls

139 lines (92 loc) · 4.2 KB
Raw

SpaceAPI Telco April 2024

Date: 2024-04-11 20:00-22:10 CEST
Location: The Internet
Who: danilo, timm, s3lph, raphi

Spec v15

Description field

  • SpaceApi/schema#102
  • Alternatives to description
    • access_hint
    • additional_information
    • how_to_get_in
    • location_hint
    • hint

Example:

  "location": {
    "address": "Ulmer Strasse 255, 70327 Stuttgart, Germany",
    "lon": 9.236,
    "lat": 48.777,
    "hint": "Knock three times, say Shibboleet and follow the white rabbit"
  },
  • Decision: Use hint
  • Merged into 15-draft.json

Add area key to location

SpaceApi/schema#71

  • It's valueable to have it
  • It's valueable to have multiple areas
  • Maybe it would be valueable to have a type field? Would allow to see if a space has a kitchen for example
    • Sometimes it's hard to specify a type, especially when a room is both a kitchen and a lab (or workshop)
  • Add a simple first version for now, make it extensible

More or less like this:

  "areas": [
     {
       type: "kitchen",
       square_meters: 12.5,
       ...
     }
  ]

We agree that this should be the way to go. To be done: Bikeshed actual format via GitHub.

MQTT broker field

SpaceApi/schema#79

  • Not useful without standardizing a clear schema
  • All examples mentioned in PR are already part of the current SpaceAPI, so why duplicate them?
  • We tend towards rejecting the PR, but will ask for concrete use cases first.

Decentralize directory (using linked spaces)

SpaceApi/directory#144

SpaceApi/schema#92

Two use cases:

  • Bootstrap a directory by crawling and aggregating linked spaces
  • Show a nice list of related spaces on a website or in an app like MyHackerspace

Problem: Once spaces are linked, how are these links updated when they change?

  • It's annoying to update a SpaceAPI endpoint if multiple spaces link to it. One needs to notify all of them.
  • OTOH domains can change too. In many cases over the last few months, domains actually did change.

Problem: Looking up endpoints indirectly through the website adds complexity to clients.

  • Aggregation services can be used to solve this issue
  • On the other hand, some clients like MyHackerspace could currently resolve endpoints, but not other resolution methods like HTML meta tags or .well-known directories.

Why not both:

  • Both an endpoint URL and a website can be specified
  • Discussion: Should one of them be required?
    • If not, we may fragment the ecosystem a bit, clients that only support one of the methods can only see parts of the "full network".
    • If we make the endpoint required, then the more flexible lookup methods lose some of their appeal
    • If we make the website required, then we add required complexity to clients
    • Not requiring endpoint URLs has the advantage that spaces which don't currently implement SpaceAPI can still be linked

Decision after long discussion:

  • Rename url to website
  • Support both website and endpoint, at least one of them must be provided (with anyOf requirement)

Power generation

SpaceApi/schema#105

  • Remove mW type, as it's redundant (there already is W)
  • Merge!

Sensors Cleanup

  • Check all sensors for redundant units, e.g. mW vs W. Potentially remove them.
  • Fix description for unit in power consumption, remove references to "flag of a boolean type" and don't suggest that the unit is optional

SpaceApi/schema#109

Optional location

SpaceApi/schema#106

Decision:

  • Remove type field, make location optional

Update CHANGELOG

https://github.com/SpaceApi/schema/blob/master/CHANGELOG.md

Upcoming v15 changes are missing.

PR: SpaceApi/schema#110

New Members?

  • Maybe somebody from spaceapi.ccc.de would want to help maintain?

Validator Repos