When I look at the possibilities to provide an endpoint, I see quite some exotic choices and it doesn't provide the sensor + edge component
I created the implementation for an endpoint using NodeMCU, microPython and PHP on any server you like. It's very simple to get started. We used it during the Hacker Hotel event. See this post.

I would like this repository to be added to the 'provide Endpoint' page. It allows people to get started quite easily and then apply to spaceapi.io to get their endpoint in the directory.

You can find it here:
https://gitlab.com/jhaand/hacker-hotel-space-state

Hi.

when I have a look at spaceapi.net, I do not see that spaceapi.io does exist. I think, the redirect could be more prominent.

Hey,

it seems that lektor has requirement Werkzeug<1 while flask has requirement Werkzeug>=2.0, hence statisfying the requirements is not possible. Does anyone else is facing this problem?

Regards,
Max

In the docs (https://spaceapi.io/pages/docs.html), enum values are not listed. E.g. for issue_report_channels, the allowed values are not shown.

JSON schema can be found here: https://github.com/SpaceApi/schema/blob/master/13.json

This must be fixed in https://github.com/SpaceAPI/website/blob/master/generate_api_docs.py.

The author name should not be linked.

Example: Home assistant.

It would be good to have a list of SpaceAPI implementations in different programming languages. Probably in some kind of table:

API endpoints should return a HTTP200 status code. Furthermore, they should set the Access-Control-Allow-Origin: * header.

Looks like http://spaceapi.net/ is borked. Are there any plans to place a redirect to a new version?

I would only keep this page http://spaceapi.net/documentation somewhere around. The style is clean and usability is better than current https://spaceapi.io/docs/

Currently we just have the text "SpaceAPI" on the top left.

It would probably make sense to add the SpaceAPI logo there.

https://spaceapi.io/validator/ tries to load a validator.css which doesn't exist.

Current HTML code: https://github.com/SpaceApi/website/blob/master/templates/validator.html

Validator is here: https://github.com/SpaceApi/website/blob/ba32846f47706d64938296ee03cbd6cf55823f09/webpack/js/validator.js

If someone wants to work on this, it's fine to completely throw away the current code and rewrite it!

A solution with as few dependencies as possible is welcome, to make maintenance easier.

directory.spaceapi.io serves the wrong content type:

% http -h https://directory.spaceapi.io 
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Tue, 21 May 2019 19:14:51 GMT
Transfer-Encoding: chunked
Vary: Origin

Compare it with https://spaceapi.fixme.ch/directory.json

% http -h https://spaceapi.fixme.ch/directory.json
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Content-Length: 10383
Content-Type: application/json
Date: Tue, 21 May 2019 19:19:01 GMT
ETag: "453735789"
Last-Modified: Sun, 19 May 2019 21:30:07 GMT
Server: lighttpd/1.4.35
Strict-Transport-Security: max-age=31536000

It would be nice for people new to the SpaceAPI to be able to have a getting started guide which explains how to get a minimal static only SpaceAPI implementation up and running.
A good way would be via static hosting on GitHub or GitLab. Something like:

• Set up an account on gitlab.com for your hackerspace.
• Create a repository (example content, TLS activation, ...)
• Create a PR to the directory repository
• ...

This fork aims to revive the development activity around the Space API. But we're always ready to discuss joining our forces back with the original project!

When acces https://spaceapi.io website I get a ERR_CERT_REVOKED error.

spaceapi.io is one of the sites that have to (manually) renew certificate, see Lets Encrypt blog on :
https://community.letsencrypt.org/t/questions-about-renewing-before-tls-alpn-01-revocations/170449

We're using scsscompile to compile our scss files now.

So far we're using webpack only to trans pile (not necessary anymore https://kangax.github.io/compat-table/es6/) and uglify the validator javascript, we might be able to remove it and remove the dependency.

See SpaceApi-archive/SpaceApi.github.io#3

All resources should be local.

The new app my-hackerspace is hosted here: https://github.com/spaceapi-community/my-hackerspace/
and it available on f-droid: https://f-droid.org/repository/browse/?fdid=io.spaceapi.community.myhackerspace
I created this issue: spaceapi-community/my-hackerspace#13

The question for me is: should the old/unmaintained app be still listed next to the new one or should the entry be modified to just show the new app?

Maybe also see #15

The local development environment could be easier / more including.

What can we do? What should we consider?

After doing a PR to the schema repo recently, it turned out that the validator doesn't accept HTTP pages even if CORS is enabled. Would be helpful to let the user know somehow - either detect "http://" in the URL and show a debugging message, or at least add a "Are you using HTTP? It might not work due to mixed-content policy" note to the debug log entry that is shown when the fetch fails (one that tells you about CORS). I've seen the "use debug console" suggestion in other issue, but the validator itself doesn't tell you that you can use it as a debugging tool - at the very least, a note about that would be helpful.

Tracking issue

Why is spacefed for example marked as required but api is not.
If I validate without api in it, the validator raises an error {"valid": false, "message": "Data does not contain an "api" field"}, but if I omit spacefed the validator gives me {"valid": true, "message": null}

It can be found here: https://github.com/SpaceApi/website/blob/master/logo/favicon.ico

I noticed, that since quite some time GitHub pages set the CORS header access-control-allow-origin: *, which means it should work quite well to host static information about a space.

curl -i -L rnestler.github.io 2>&1 |grep access-control
access-control-allow-origin: *

The website layout looks ugly on mobile browser. We should probably add some responsive design magic 😉