Skip to content

Latest commit

 

History

History
195 lines (134 loc) · 6.91 KB

20200510-telco.md

File metadata and controls

195 lines (134 loc) · 6.91 KB
Raw

SpaceAPI Telco May 2020

Date: 2020-05-10
Location: The Internet
Who: cyroxx, danilo, jssmk, raphi, timm

Previous meeting: 20200329-telco.md Next meeting: 2020-08-09 20:00 CEST

1. Agenda

  • Status
  • Website Refactoring
  • 0.14 Release
  • Decentralized Directory
  • Add todos as issues?
  • spaceapi.net
  • Todos

2. Status

Danilo:

Raphi:

  • spaceapi-rs 0.14 support
    • Not yet done
  • Test website from SpaceApi/website#66
  • Ask g5pw and s3lph to join next meeting
    • Asked s3lph, but no-show. Didn't contact g5pw
    • g5pw -> IRC hackerspaces channel

Timm:

  • TLS issue on Android 4/5
  • Add a warning on our website that spaceapi.net is deprecated
  • DNSSEC
    • Waiting for provider to add DNSSEC support to the control panel
  • Website refactoring

3. Website Refactoring

4. 0.14 Release

  • Tracking issue
  • Should we release v14 instead of v0.14?
    • Stronger signal that things changed
    • We don't have semantic meaning in the version
    • The schema JSON files are already numbered 12, 13 and 14
    • -> Let's release v14 instead

5. Decentralized Directory

Use-Case: hacklab.fi wants to add hackerspaces to the directory without the need to open a pull request, that might be solvable by a decentralized directory.

Maybe something like a web of trust? Or federated directories?

  • How about a decentralized directory?

    • Link to other directories from directories

  • Timms Idea (links-to field):

    • The central directory parses all the endpoints which may link to new endpoints
    • If it finds new endpoints it adds them to the central directory
    • If they disappear / are not reachable, they get removed from the directory
    • Downsides:
      • Complexity is way higher
      • Removing a space is hard

Each space can have a field called "linked_spaces" which contains links to other SpaceAPI endpoints.

This should be used to build up a network of interlinked SpaceAPI endpoints. You could for example add all spaces that you know personally ("friends list"). You could also list all spaces in your country. The idea is to enable a way to crawl the whole network even without a central directory.

Let's discuss this on the GitHub issue with the actual proposal.

Example

{
  ...,
  "linked_spaces": [
    {
      "endpoint": "https://spaceb.hacklab.fi/spaceapi.json"
    },
    {
      "endpoint": "https://tarlab.hacklab.fi"
    }
  ]
}

What to use as identifier for spaces?

Currently we use the Space name as the unique identifier for a hackerspace. But the hackerspace endpoint could define a different name in their JSON.

So it would be better to use the Space website URL (Or the JSON URL? that one changes more often) as a unique identifier.

Also when using the JSON URL with the "linked_spaces" field this could lead to the problem the an endpoint ends up multiple times with a slightly different URL (http://space.example.com, https://space.example.com, https://space.example.com/).

.well-known/spaceapi.json

  • It's hard to list several hackerspaces under a single domain (would need subdomains for each)
  • It's not possible to host on GitHub / GitLab pages

Resources

https://github.com/hacklab-fi/hacklab-website/blob/master/_data/kaupungit.yml The data hacklab.fi uses on their landing page for drawing a map and making other types of listings of member spaces.

This is what UK Hackspace Foudation uses in their django db model. https://github.com/UKHackspaceFoundation/website/blob/master/main/models/space.py Also used for mapping and listing purposes: https://www.hackspace.org.uk/

These might be more or less or more organized. Not much known how much they look after their listings accuracy, or how much these are actually networking with each others. They might be more "artificial" or "just lists" than closely co-operating networks like UK HSF or hacklab.fi: http://www.makersofsweden.se/ http://norwaymakers.org/

6. Add todos as issues?

So far we have two lists:

  • The ones in the protocol
  • Issues on GitHub

Todos here could be transformed to Issues on GitHub. If they don't belong to any repo add them to the meeting note repo.

The point is to have a GitHub issue for most tasks.

7. Spaceapi.net

Registrar Registration Expiration Date: 2020-05-16T22:19:58Z

Grab it and redirect to spaceapi.io :)

Got renewed :/

Varia

jssmk First Contact experience

Had a bad encounter on the IRC channels. We're sorry about that.

Also we are a bit bad about communicating what the purpose of the project is and where we are headed.

Mattermost / Matrix

Danilo: Mattermost needs a separate app, which is kinda annoying for an open source project.

We don't use the channels really. Schema discussions happen on GitHub, Directory discussion in this meeting.

Matrix wouldn't need a separate app (The mattermost app can only handle one server).

Danilo will set up a channel on the Coredump Matrix instance and bridge it to the IRC / public room.

Announce meetings

Sombody wrote in the chat:

cyroxx: Because I couldn't find the announcement for today neither in Github nor on Twitter. Will check today's protocol later, though 😉

Should we announce our meetings more prominently? On the website?

Country?

Should we add it to the schema? Would allow to filter by country easier than using the lon/lat property.

Timm: It is redundant data.

jssmk: Their index has the openstreetmap node ID. With this ID you can gather more information very quickly. We could add it to the schema 😃

Danilo: I'll add a proposal to the schema repo, where we can discuss these two things.

X. Todos

Timm:

  • Create schema proposal for "linked_spaces"

Danilo:

  • Handle v0.14 -> v14 versioning schema change
  • Is there a nice OpenAPI code generator to handle parsing?
  • Set up Matrix channel, bridge it to IRC and to the old mattermost public channel, remove link to chat from website
  • Schema issues regarding country / osm node id
  • MyHackerspace release
  • Review SpaceApi/website#66