jceb81

Thank you for your feedback Yes, you can easily pass the URL of the README.md to slidesdown via the ?slides=URL query parameter and it will load that file instead of SLIDES.md. Here's an example: https://slidesdown.e-jc.de/?slides=https://github.com/jceb/s...

I created Slidesdown, a zero installation presentation tool, that just takes a link to a public Markdown file and creates a beautiful presentation out of it.

In version v0.2.0 hot-reloading and offline support were added as well as a small shell script for serving presentations from the local hard-drive.

The example presentation can be found here: https://slidesdown.e-jc.de/

One particular use case I have in mind is to allow software maintainers to pitch / show case their projects by creating a SLIDES.md file that lives right alongside README.md. A direct link can be generated via https://slidesdown.e-jc.de/loader.html and shared on GitHub and beyond.

I'd love to hear your feedback. Would you be interested in adding a SLIDES.md file?

I recently moved from fish to nu. Fish provided the best experience so far. My reasoning for switching to nu is to move closer to a programming language in my shell. Overall, I'm very happy with nu, especially after they added support for direnv.

I created Slidesdown as a zero installation presentation tool that just takes a link to a public Markdown file.

The example presentation can be found here: https://slidesdown.e-jc.de/

One particular use case I have in mind is to allow software maintainers to pitch / show case their projects by creating a SLIDES.md file that lives right alongside README.md. A direct link can be generated via https://slidesdown.e-jc.de/loader.html and shared on GitHub and beyond.

I'd love to hear your feedback. Would you be interested in adding a SLIDES.md file?

Here's the link: https://www.microsoft.com/en-us/security/business/solutions/...

I haven't used their implementation yet but Microsoft initiated the did:ion method. I guess they'll support it :-D In general, the idea with DID methods is that you can support many methods without too much effort - for example the Universal Resolver implements already a good bunch: https://dev.uniresolver.io/

However, pointing in the direction of the many DID method implementations, I agree with you that they're confusing. Many people try their hands on implementing a new method. Most of the methods will not amount to much. I recommend focusing on simple methods like did:key or did:web to get started and high throughput methods like did:ion, did:elem, did:orb (all sidetree based) for production. did:ethr is also a good starting point for a public blockchain DID method that doesn't require a transaction to create the DID, i.e. no expenses required. did:ethr is also one of the oldest methods and can easily be used in existing Self-Sovereign Identity software solutions.

DIDs support multiple storage mechanisms. Each storage mechanism defines how to create, read, write/update, and delete DIDs. Here's a list of the already implemented and published mechanisms: https://w3c.github.io/did-spec-registries/#did-methods. They range from no storage (e.g. did:key, you derive the DID from a public key but can't change/update anything about that DID) to stored on a webserver (e.g. did:web) to stored on a blockchain (e.g. did:ethr).

Often, a DID is created from a public/private key pair that is used to sign a transaction that's specific to the DID method. The DID then becomes publicly visible with the associated configuration, e.g. multiple key pairs associated with the DID, service endpoints that allow an interaction with the DID, etc.

Microsoft has already lined up the tech in their products. So I'm confident that it's just a matter of time before it becomes available in a shop nearby.

It depends on the DID method that you're using. The DID method is kind of the identity management system for Decentralized Identifiers. Many DID methods are based on blockchains and with that there are usually no recovery mechanisms for DIDs in place - if you lose your private key the identifier can't be updated and you can't prove ownership over the identifier anymore which in turn renders associated credentials (see Verifiable Credentials https://w3c.github.io/vc-data-model/) unusable.

Custodial services are a good way out. Another option with DIDs is that you can add more than one key to DID. This way you can have one key that is stored away somewhere safe and is only used for recovery purposes.

Microsoft already has their own Decentralized Identity products in place. Check out https://www.microsoft.com/en-us/security/business/solutions/... They are and were also actively involved in the creation of standards and tooling, e.g. the did:ion sidetree-based DID method was created by them.

Great work, I find it very helpful