DEV Community: Fission

Headless Ghost and Fission

agentofuser — Wed, 24 Feb 2021 16:08:56 +0000

We're exploring a number of "Headless" combinations at Fission. The first one is with the Ghost Content Management System (CMS). We use Ghost to run our blog and want to start using it to integrate with and power our home page, so it's a great place for us to start.

The basic pattern of "Headless" is that your authors and editors login to a server based system with all the authoring and editing tools they are used to, but then the "head" – the usual template system and user facing website – isn't used. Instead, a modern front end framework is custom designed and built to take the published content of the CMS and host it. This fits great with the Fission app publishing platform.

After we've got the basics of a headless publishing workflow setup with Fission, we'll move on to using our Webnative framework to add personalization at the edge, but that will come in later posts.

Aside from Ghost, we're also looking at Headless WordPress and Headless Drupal. Let us know in the forum if you've got other Headless projects that you'd like to combine with Fission!

Build a Next.js Blog powered by Headless Ghost and Fission

You want to have a modern static website/app built with React, deployed to a CDN (even a distributed one), and loading super fast for visitors and search engines.

You want to avoid the headaches and costs of managing and securing servers for traditional content management systems (CMSs) like Ghost and WordPress.

That's what static site generators (like Next.js, Gatsby, and others) are for, right?

But, you don't want to have to retrain every writer and content creator on your team to use Markdown and Git. Ghost and WordPress are familiar, pretty, and usable. They have been iterated over years to be approachable by almost anyone.

What do you do? That's right you cut the CMS' head off 🔪

More politely, you decouple the interface used for authoring content from the systems used for rendering and distributing it.

With CMS and website decoupled, you can protect the CMS inside an intranet without exposing it to outside danger, or even use it as a desktop word processor running only on your machine, as I'll show you in this tutorial.

To make things easier we've made a template Next.js website that connects to Ghost and pulls content from it. Follow along and try it out. Feedback welcome :)

This starter template is based on the official blog-starter-typescript from Next.js.

We changed it only enough to make it possible to fetch and publish blog posts from the Ghost CMS, while keeping the ability to write Markdown files in the git repo. It's a purely additive change.

There's also a GitHub Action to build and publish the static website to Fission. It works automatically on pushes to the git repo, and can be triggered manually after updating the content on Ghost. (The default Ghost webhook isn't customizable to trigger a GitHub Action, but that can be added as a plugin.)

The Markdown blog posts are stored in /_posts as files with frontmatter support. Adding a new Markdown file in there will create a new blog post.

The Ghost blog posts are fetched using Ghost's Content API library.

✨ Getting Started

Let's start by making this starter yours:

Click Use this template at the starter page on GitHub

That will make a copy of the starter into a new repo under your account with a fresh git history. You can pick a different name for it too; in that case replace nextjs-blog-starter-typescript-ghost with your chosen name below.

Clone the repo (replace with your own URL):

  git clone git@github.com:fission-suite/nextjs-blog-starter-typescript-ghost.git

cd into the repo:

  cd nextjs-blog-starter-typescript-ghost

Install dependencies

  yarn

All command-line instructions and directory paths from now on assume the current directory is the root of the cloned repo.

👻 Setting Up Ghost

Public or Local Ghost?

Running a local Ghost instance is good for testing. But also, if you have no need for a Ghost instance running all the time out on the internet (for example, if you are the only author) you can do this for your production website, using Ghost locally for its nice interface if you prefer that to editing Markdown files. No servers to secure, no bills to pay.

Setting Up Local Ghost

If you have a Ghost instance running already somewhere, move on to the next step. If you don't, you can set one up on your own machine with Docker.

To create a local Ghost instance with Docker, run the following at the root of your repo:

yarn ghost-local-create

Ghost data will be stored at ./ghost, which is in .gitignore by default. In a private repo you can choose to commit that too and have your Ghost content versioned and available whenever you need it.

There are other scripts like ghost-local-start, ghost-local-stop, and ghost-local-remove which you might find handy to manage the Docker container.

After Docker downloads and sets up Ghost, it will be accessible on your browser at http://localhost:3001.

Next you need to create an admin account on your newly-created Ghost. To do that, visit the admin interface at http://localhost:3001/ghost and follow the wizard.

Exposing the Ghost Content API

I'll use http://localhost:3001 for the examples, but you can replace that with your Ghost URL if you have an instance already running somewhere else.

Go to the admin interface at http://localhost:3001/ghost
On the left-hand sidebar, click on "Integrations"
On the Integrations screen, click on +Add custom integration
Give it a name, like nextjs, and click "Create" then "Save"

Now the important part:

On the same screen, you'll find two fields we need: Content API Key and API URL
Copy those into a new .env.local file, like this:

# .env.local
# replace values with your own
GHOST_API_URL=http://localhost:3001
GHOST_API_KEY=2a9356e4a5214c883ba886e58e

⚠️ This file is ignored by git by default. Don't commit env.local to git unless you know what you're doing.

Alright! Ghost part's done.

💻 Running Next.js Locally

Next.js is the missing static website head to our *head*less Ghost. Let's stitch them together! This should be enough:

yarn dev

Your blog should be up and running at http://localhost:3000! (If anything unexpected happens, please post an issue.)

Now you can change the Next.js website code and the content on Ghost, and iterate quickly on them in the browser.

Note: live-reload works for Next.js code and Markdown files; to see changes to Ghost content you need to refresh the page.

🌐 Deploying to Fission

When you're ready to publish, the first step is exporting your website to a set of static files:

yarn build

That should create a directory at ./out with all your ready-to-publish files.

Next we use the Fission CLI to send that out onto the internets.

🔰 Fission CLI Install and Sign Up

To install the Fission command-line interface using brew, run:

brew tap fission-suite/fission
brew install fission-cli

For more ways of installing the Fission CLI, please check the documentation.

If you don't have a Fission account, you can create one without leaving the command-line by running:

fission setup

🌱 Register New Fission App

You can pick a subdomain or let Fission choose a random one for you.

To host the Next.js website at a random subdomain on .fission.app, run:

fission app register

To choose your own subdomain, use the --name option like this:

fission app register --name my-beautiful-subdomain

That will create a fission.yaml file. This one is safe to commit to git, and you should do that if you want to use the GitHub Action to build and deploy the website for you. Make sure there is a line saying build: ./out in it. That's the directory where Next.js puts the exported website files.

🚀 Aand... Launch!

One last step:

fission app publish

And you're done! Your website should be up at a random URL returned to you by the Fission CLI or at my-beautiful-subdomain.fission.app if you used the --name option. Yay!

🤖 (Semi-)Automatic Deployment with the GitHub Action

If you don't want to run the build locally and deploy to Fission every time you make a change to the Next.js code or Markdown files (who does?), this starter comes with a GitHub Action that automates that for you.

To get it working you need to set up 3 secrets for your repo. To do that, go to the "Settings" > "Secrets" screen on your GitHub repo, then create a "New repository secret" for each of these:

GHOST_API_URL
GHOST_API_KEY
FISSION_KEY

The values for the GHOST_API_ fields are the same ones you used for the .env.local file above.

The FISSION_KEY was created and stored locally for you by the Fission CLI when you set it up. Here's how you get it:

cat ~/.config/fission/key/machine_id.ed25519 | base64

With all 3 secrets set up, you can trigger the deploy action manually by clicking on "Run workflow" > "Run workflow", or see it in action after your next git push.

Note:

⚠️ To fetch the content from Ghost, the GitHub Action must be able to access the URL entered in the GHOST_API_URL secret.

If you are running a local Ghost instance on your machine, http://localhost:3001 won't be visible to the outside.

A simple way of exposing your local Ghost instance to a publicly-accessible URL is by using one of the open source alternatives to ngrok or ngrok itself.

With ngrok you do something like this:

ngrok http 3001

⚠️ This is great for testing, but not secure. Look into using https if you're going to rely on this and don't want your Ghost API key and data to leak.

Why "(semi-)" automatic then? 🤔

Glad you asked. The GitHub Action can detect when you push to the GitHub repo because there's a built-in "on push" event that can be used to trigger it.

But when you create a new post on Ghost or update an existing one, GitHub needs a way of finding out about it so it can run the deploy action. There's no git push event happening, so the trigger is usually a webhook (i.e. a POST request you send to a GitHub API URL.)

🙂 Luckily, Ghost comes with the built-in ability to send webhooks when content changes happen.

🙃 *Un*luckily, though, Ghost doesn't let you customize the payload that goes in the webhook requests it sends, and GitHub requires a certain field to be present telling it which ref (usually a branch) you are referring to.

Bottom line: after changing things on Ghost, you need to trigger a build manually.

You can do that via the GitHub interface ("Actions" > "Continuous Deployment" > "Run workflow" > "Run workflow"), or by running the handy script we added to this starter:

GITHUB_USER=your-username GITHUB_REPO=your-repo GITHUB_AUTH_TOKEN=your-auth-token trigger-github-deploy-action.sh

Here's how you can get an auth token.

This situation is definitely not ideal, and can be solved with Ghost plugins, but we wanted to stick to the basic install.

🙏 Show your support

Please give a ⭐️ if you liked this project! We appreciate it :)

Fission Fragments May 27th Weekly Links

Boris Mann — Wed, 27 May 2020 23:35:39 +0000

Fission Fragments is our weekly links roundup, that has been on hiatus ... for a while. We're going to get back to weekly, usually Wednesdays, and will be posting in the forum. You can also subscribe by email.

Alcro, an Electron competitor that uses Chrome devtools and websockets

Via @bascule, we found out about Alcro:

Tony “Abolish ICE” Arcieri 🦀

@bascule

Alcro: a Rust library for building desktop apps using web technologies by leveraging an existing installation of Chrome (rather than shipping the entire Chromium/Blink engine for each app like Electron)
github.com/Srinivasa314/a…

18:50 PM - 21 May 2020

2 18

🔗

Tauri Studio - An Electron competitor that uses webview

Found via the bascule Alcro Twitter discussion, Tauri is another project to build native desktop apps with web technologies. It features a Node based CLI and a Rust backend, although the project aims to be polyglot:

Today, Tauri uses Rust for the backend - but in the not too distant future, other backends like Go, Nim, Python, Csharp etc. will be possible. This is because we are maintaining the offical Rust bindings to the webview organisation and plan to let you switch out the backend for your needs. Since our API can be implemented in any language with C interop, full compliance is only a PR away.

🔗

Git LFS with IPFS Support

As part of some ongoing research, @ellttBen found an implementation of Git Large File Storage (LFS) integration with IPFS, sameer/git-lfs-ipfs.

This has given us some good ideas of how to integrate a git-based development workflow with IPFS and Fission.

Binary files of all kinds can be stored with your git repo, but then transparently stored in IPFS, rather than checked in and bloating the size of your repo. This could be particularly interesting for large photos, videos, and in general media files and assets.

🔗

Slack vs Discord vs Discourse: the best tool for your community, Orbit Blog

Our friends at Orbit (you know, makers of the Orbit Model of Developer Engagement, also in our forum) wrote up a giant community platforms blog post that’s a really good summary of pros and cons to help you decide Slack vs Discord vs Discourse.

We’re on Discord and Discourse, and also use it for our private / internal company spaces, too, which isn’t really covered in the Orbit post. We’ll get around to writing up our story at some point!

🔗

Anil Dash, CEO of Glitch, says we need "Yes Code" rather than "No Code"

At the beginning of May, Anil posted No Code is great, but here's why we need Yes Code to LinkedIn.

We believe in a lot of these same concepts at Fission, along with additional step of making it so that users can own their own data, which should make it even easer to hack and remix apps and websites.

🔗

I want to own the database that my apps use, Grant Orndorff

Speaking of things we believe in and owning user data, Grant's post about how he envisions users owning the data of apps they use is very similar to what we're building at Fission. He covers SOLID and Urbit and how they're not quite what he has in mind.

🔗

Fission Updates

Brooke explains her design of UCAN, a user authorization method that doesn't need a backend, that we're implementing at Fission:

User Controlled Authorization Networks (UCANs) are a way of doing authorization where users are fully in control. OAuth is designed for a centralized world, UCAN is the distributed user controlled version.

This week's video chat is with Qri, an open source version control and sharing system for datasets, built on IPFS -- join us Thursday, May 28th, at 9am PDT / 12noon EDT / 1800 CEST.

Fission is building a web native file system, plus tools to build & host apps with user controlled data, encryption, and local first software. This makes it easy for front end devs to build great apps without worrying about backend or deployment.

Experimenting with HLS Video Streaming and IPFS

Boris Mann — Wed, 22 Apr 2020 17:09:39 +0000

We've been running weekly developer lunch & learn sessions over video. I've been downloading the video from Zoom, doing some basic trimming, and then uploading it using Fission, and embedding the IPFS link in our Discourse forum. This works pretty well – Discourse recognizes the video file extension and embeds a video player in the post automatically. I had read a bit about HTTP Live Streaming (HLS) and wanted to experiment.

Originally developed by Apple, and now widely supported, HLS doesn't need any special server-side support. A bit more in this freeCodeCamp article:

The most important feature of HLS is its ability to adapt the bitrate of the video to the actual speed of the connection. This optimizes the quality of the experience.

HLS videos are encoded in different renditions at different resolutions and bitrates. This is usually referred to as the bitrate ladder. When a connection gets slower, the protocol automatically adjusts the requested bitrate to the bandwidth available.

– freeCodeCamp: HLS Video Streaming: What it is, and When to Use it

There's an example in the JavaScript implementation of IPFS about using HLS with js-ipfs. The README explains:

The fact that HLS content is just "a bunch of files" makes it a good choice for IPFS (another protocol that works this way is MPEG-DASH, which could certainly be a good choice as well). Furthermore, the hls.js library enables straightforward integration with the HTML5 video element.

"Just a bunch of files" is pretty much how we're thinking about Fission. Fission and any standard IPFS gateway serves up files over HTTP and/or natively with IPFS, without plugins, in any browser. It's really great to get back to what is basically the 2020 equivalent of upload files to the server.

I took the latest video file of Joel talking about Ceramic Network and ran the ffmpeg command from the js-ipfs example. On MacOS, brew install ffmpeg will get you the program.

ffmpeg -i ../YOURVIDEO.mp4 -profile:v baseline -level 3.0 -start_number 0 -hls_time 5 -hls_list_size 0 -f hls master.m3u8

On my desktop iMac, the progress showed to be encoding at 4x - 5x speed. The video is about an hour, so it took about 20 minutes to complete. The output is 400+ files, which I uploaded with fission up and then noted down the hash of the folder.

Browse the files on IPFS using Fission Drive

Then I went back and edited the streaming.js folder and index.html. The streaming.js file just needs the hash of the folder that contains the HLS-encoded video, which for this video is QmYGs1ksGX3eMiGvxNuvRT6PD7zPKZpHyiUDXKGQoL4R7S. Feel free to use this to experiment with! I kept the master.m3u8 file name so didn't need to change that.

One change I made was to to also include the IPFS script from a CDN in the index.html file (the js-ipfs example assumes you're running things locally and working with js-ipfs from there). Just add this line:

<script src="https://cdn.jsdelivr.net/npm/ipfs/dist/index.min.js"></script>

You can browse all the files directly using Fission Drive, including the source video that was encoded. Visiting the index page will load the player and HLS stream the video.

Example HLS Video

Here's the source and video embedded via Codepen – hit the HTML button to view source. Note the Fission gateway link to the published version of the streaming.js file, also remotely included:

The video isn't very high quality to begin with, and adding width/height to the video element could constrain it to different sizes.

More about Joel and Ceramic Network on the forum event page »

Conclusion

This is a very manual process, and there are lots of dedicated video encoding services. It was a good experiment to see that anything that is a "bunch of files" can just work over the distributed IPFS network, and easily published and hosted on Fission.

Experimenting with a large, high quality video and testing across different devices and network speeds (and whether or not nearby peers had a copy of the video) would need to be done vs. just embedding the original video to see what the user experience is actually like.

This also leads to some interesting thoughts about distributed encoding. Once an original video is encoded and added to the network by one person, it never needs to be encoded again. From some brief research, ffmpeg is not deterministic, which lead to this thread on Mastodon. This means that different people encoding a video could get different output files, which means different hashes in IPFS.

However, the original video file is unique, so adding metadata to the original source video file for discovery of the unique, permanent hash of an HLS-encoded version could work.

We're currently doing some work on how to do this for images, so that different sizes are automatically available and cached in the network.

Fission is an app & web hosting platform that implements a web native file system powered by IPFS. Build and run locally, fission up to host everywhere. Read our guide to get started and sign up right from the command line.

What colour is your yak? Visualizing developer jargon

Boris Mann — Tue, 21 Apr 2020 18:05:00 +0000

We're creating illustrations for developer concepts, catch phrases, and other jargon. Yak shaving is one of those terms. It's fun to dig into the concepts and learn about their background, teach other people about them, and we get some cool images to use in a number of different ways that aren't just company branding. We have ideas for some new illustrations, we're happy to take other suggestions and have people vote for their favourites.

Bear and Penguin

We had fun last year sourcing the Bear and Penguin illustration for the Berlin Open Source Salon. The inner meaning here is that the bear is the coat of arms for the city of Berlin – the "Berliner Bär". The bear is holding a Club Mate drink, traditional drink of German hackers (although I know at one time the Mozilla Vancouver team imported it for their office fridge, too!). And the penguin is the long time mascot of Linux.

Wizards and Snakes

Since then, we've worked with Bruno Monts, an illustrator based in Brasil, to create a number of other illustrations.

We just released the Haskell Wizards series, written up in our Haskell for Typescript Devs book:

SCREAMING SNAKE CASE was just a pure piece of fun, with the vaporwave stylings pushed to the max. We did a first run of stickers with this image, and can't wait to come up with t-shirts or other swag with this fun image:

Vote for developer jargon to illustrate

We're going to get some more illustrations made, and have a couple of ideas already:

Kebab case wouldn't be vaporwave, but maybe a sort of comic / graphic art – a delicious kebab, dripping sauce.
The Elm programming language is a favourite of ours at Fission, so vote for this one if you want an Elm-y character in the style of the Haskell Wizards
We recently added some definitions for Yak shaving to our forum. It's only about 20 years old – but of course software development has changed dramatically in the last 20 years, so it's a term that's not well known.
Bike shedding and
Pets vs. Cattle are the last two suggestions we have so far.

We're working with Bruno now, and will run the vote for a couple of weeks, and then get at least 2 or 3 of the developer jargon ideas turned into high quality illustrations.

Post header photo by Lieve Ransijn on Unsplash

Fission on the IPFS Community Call

Boris Mann — Mon, 09 Mar 2020 19:34:27 +0000

Thanks to the IPFS team for hosting us on the weekly community call! These community calls happen weekly on Mondays at 1600 UTC.

We presented an intro to what we're building at Fission, including our hosted services, open source contributions, and more.

We've started to use the phrase "web native apps" to describe Fission's app creation platform that decouples storage from apps, with user controlled data, and secure by default. Which is what is expected by users from native mobile apps.

You can watch the video on the IPFS Youtube channel here:

The slides are available on IPFS as a PDF:

Also on Notist

From the final slide, here are all the places where you can find out more and connect with us:

Github: fission-suite
Install Guide & Docs: guide.fission.codes
Technical Whitepaper: whitepaper.fission.codes – this is a work in progress! 🚧 👷‍♀️✍️
Discourse forum: talk.fission.codes
Discord chat: fission.codes/discourse
Twitter: @fissioncodes, team accounts @expede, @bmann, @icidasset, and @dholms on Github

Fission Drive Preview

Boris Mann — Thu, 13 Feb 2020 18:51:41 +0000

We're pleased to present the Preview release of Fission Drive , the web native file system browser that we're including as a base component of the Fission stack.

We've been hosting files, static websites, and client-side apps on Fission since we launched our CLI tool in October of 2019.

Underneath, we use IPFS, but increasingly that's a detail that we don't think most users of our service should have to care about. It's a dependency, just like using MySQL or Redis.

Of course, if you do know what IPFS, great! We want to make it as easy to use as any existing Web2 component, while having capabilities at the protocol level – like file de-duplication, a global CDN, peer-to-peer sync, immutability, and offline support, to name a few– that let us empower all developers to build new and interesting tools.

Fission Drive is the app that we're building to showcase what the entire Fission stack can do, hosted on our own infrastructure.

Steven @icidasset joined the team in December and has been full time since January. He designed and built Fission Drive, as well as our slick new home page, which is also now running on Fission. Next up for Steven is building out web-based passwordless login for Drive, as well as the TypeScript libraries that will let all developers build apps like this.

Drive has a few features to play with, like image previews and support for dark mode. We'll keep the guide docs updated as we add features.

Fission Drive in Dark Mode, with an image preview

This preview release supports browsing any public IPFS hash, not just those on Fission. You can use this example hash QmbCLefkFuXbhHBWSW7PWmJzBL7W7e8zm41HK4DGJ1RDwV to see it in action at drive.fission.codes.

Want to add your own files? Follow the install instructions for the Fission CLI to easily upload using fission up.

You can subscribe to keep up to date with Fission Drive and other product updates.

Screaming Snake Case

Boris Mann — Tue, 28 Jan 2020 20:24:20 +0000

Did you know that different programming languages and certain developer preferences have led to different standards in naming functions, variables, constants, and other programming terms?

Camel case (wikipedia) – or should I say, camelCase – is probably the best known programming naming convention, in either PascalCase (initial capital) or dromedaryCase versions.

While researching, we were delighted to learn about kebab-case -being-a-thing, and you can find a bunch more letter cases on Wikipedia.

But we're here to tell you about snake_case :

The use of underscores as word separators in identifiers in programming languages is old, dating to the late 1960s. It is particularly associated with C, being found in The C Programming Language (1978), and contrasted with PascalCase (a type of camel case). However, the convention traditionally had no specific name: the Python style guide refers to it simply as "lower_case_with_underscores".

Within Usenet the name "snake_case" was first seen in the Ruby community in 2004, used by Gavin Kistner

https://en.wikipedia.org/wiki/Snake_case

This, of course, leads us to SCREAMING_SNAKE_CASE – all capitals, often used when defining constants.

And now, a vapourwave inspired illustration:

We're a developer focused company, which means we have fun with developer-centric in jokes and illustration. We've made a first run of stickers that you can fill out your postal address on our swag signup page and we'll get some sent to you.

We've got some other programming related illustrations that will get turned into stickers and other artwork lined up, with Haskell -related characters being up next. Haskell also happens to be what we're writing our backend services in.

The artist behind this first set of work is Bruno Monts , a freelance illustrator and designer from Brazil. You can see his portfolio on Behance. Thank you Bruno for your great work!

Stay tuned for more fun developer art!

IPFS on Hackage

Boris Mann — Fri, 20 Dec 2019 21:27:05 +0000

Authored by Daniel

We just published version 1.0.0 of our IPFS package on Hackage 🎉

This library offers a high level API for interacting with IPFS nodes. Most of the functionality was refactored out of our Web API, which provides a convenient HTTP interface for accessing the IPFS network.

The library can communicate with IPFS nodes in two different ways:

Locally: This is done by shelling out to an IPFS daemon that is running on the same machine. This would be the equivalent of running an IPFS command in your terminal.
Remotely: This is done by communicating with a node's HTTP interface. This could either be a node running on the same machine or on another machine.

The package is not currently fully featured, but the base functionality is present: add, get, pin, and dag put (for building IPLD structures). The existing code provides helpful building blocks for adding additional functionality.

Check out the code on GitHub. Let us know what features would be helpful for you and any issues that you might run into along the way!

When you're ready to start building, head over to Hackage and grab the library.

IPFS Storage Adapter for Ghost Blog with Heroku Deploy

Boris Mann — Fri, 20 Dec 2019 00:51:05 +0000

Back in May, as part of putting the Fission blog on Ghost, I packaged it up to be a one-click deploy on Heroku. We've gone one step further and gotten an IPFS Storage Adapter completed, and upgraded to Ghost v3.x.

This one-click deploy is possible because our IPFS Heroku Add-on is in beta! 🙌 🎉

Our IPFS Heroku Add-on is in beta with a free "test" plan.

This means you can package up apps to be deployed on Heroku that automatically add our add-on. This provisions you a username and API key and your app can use our Web API to read and write to IPFS, manage DNS, and anything else accessible through our API.

Check the Github repo for more details, or go ahead and deploy a new Ghost 3 blog here:

To complete the Ghost deploy, the only configuration you'll need to do is to set the public URL for your blog – e.g. https://boris-ghost-test1.herokuapp.com.

We've set the IPFS gateway to use ours by default, but you can put in any gateway you like. Images are included from this gateway, but of course using the IPFS Companion extension means you can serve the images from your local machine.

Go ahead and setup your first user, create a new post, and add an image – voila! Interplanetary Ghost Blogging! Here's my sample post.

We're working on adding IPFS support for basic file uploads to a number of other platforms. This is a first step in getting more content natively available in IPFS. Imagine managing your blog's media assets or a gallery page from your desktop, being able to login to any system and have all your photos and files available for you there.

Join our App Ideas forum to suggest other things you'd like to see. Thanks to Mike Taylor @mktlrwho for working on this with us!

A Universal Hostless Substrate for a Post-Serverless Future at Øredev 2019

Brooklyn Zelenka 🏳️‍🌈 — Tue, 12 Nov 2019 18:22:12 +0000

Brooke was at Øredev 2019 in Malmö, Sweden and presented a talk covering the evolution of server architecture that we call "hostless". This also serves as a high level technical roadmap for what we're working on here at Fission. We've shipped IPFS support, and will move on to identity using zero-knowledge proofs and DIDs, and distributed compute with WASM and smart contracts.

While those are a blizzard of next-gen technology concepts, we're integrating them in such a way as to make them usable and turnkey. The outcome is a better developer experience (DX).

Key takeaways:

There has been a 60-year progression of server architecture, and there is one final phase left
There have been recent advances in cryptography, distributed systems, and web infrastructure
It is possible to store data and run computation anywhere , even on untrusted machines
Remove the concept of “local development”, “production”, and “deployment” entirely

The last 60 years has seen the rise and fall of several models of computing: mainframes, private server, shared hosting, containers, and serverless (to name a few). We have one final phase left: “hostless” or universal apps. By leveraging technologies like secure multiparty compute, the content-addressable web, blockchain, and the rise of WASM, we are seeing the beginnings of a future liberated from specialized providers, acting on a distributed substrate of store and compute.

With all this in place, users fully control their own data (and it never touches your servers), deployment is as simple as setting a flag on your local environment, and developers maintain zero infrastructure.

Come learn about what is being built today for the next wave of computing, how we evolve past the serverless paradigm, and how it can make life simpler for developers and end users!

The slides are available on Notist.

Exporting your Facebook photos to Fission

Boris Mann — Sun, 10 Nov 2019 09:01:10 +0000

I wrote this post as a quick weekend HOWTO on the Fission blog because it turned out people were excited to try this on their own. At Fission, we're building developer tools to make it easy to build and deploy serverless apps directly from your desktop. Our first service uses IPFS, a p2p file system, so that files stream directly from your computer.

Facebook has a fairly extensive data export system built in. I decided to export my photos and videos and put them up on Fission.

For now, this is a manual process and involves some command line usage. I'll write this up as an App Idea in our forum and see if we can spend some time making this "one-click".

Jamie Burke

@jamie247

@bmann @FISSIONcodes Please make that one click for me dude

08:32 AM - 09 Nov 2019

0 2

Read the Facebook help article on Accessing & Downloading Your Information for instructions on how to navigate to the right section of your Facebook account.

On a desktop browser, it should be under the triangle in the upper right hand corner, then Settings, then Your Facebook Information, then Download Your Information.

I don't upload much to Facebook and only cross-post my Instagram photos (which are cross-posted to my personal blog), so I clicked Deselect All (says Select All in the screenshot above), and only selected Photos and Videos. I also set Media Quality to "High" (although some people still report that these are still not as large as the originals, which may only be accessible through the API).

You can experiment with including other items. But, be aware that because there aren't any permissions, you may be sharing information you don't want to if you publish the files. Same goes for the photos. I have posted most things on Facebook the assumption that they are "public".

Click the Create File button and go make a coffee. Facebook will notify when your download is ready.

Just over 13 years of Facebook.

To download, you'll need to click on the Download button and enter your Facebook password. You now have a zip file with browse-able HTML files and your photo and video files.

Putting your files online with Fission

You'll need to type a few commands into the command line Terminal on your machine, but everything should just work if you copy-paste.

Install the IPFS Desktop and run it. You've got a graphical interface to explore your local IPFS server, which is running in the background.

On Mac, make sure you've got homebrew installed, then open the Terminal app and install the Fission tools using these commands:

brew tap fission-suite/fission
brew install fission-cli

You can find extended installation instructions in our Fission Guide, and I expect our friends running Linux will have no problem.

Now, you're going to register for Fission.

fission register

Your username will be your subdomain, e.g. boris.fission.name. Pick a password and enter an email address. We are adding support for custom domain names, stay tuned!

Now, you've got a zip file in your Downloads folder from Facebook, called something like "facebook-YOURNAME.zip". Unzip it and you'll have a "facebook-YOURNAME" folder.

Back to the terminal! This is the last step!

The fission up command is going to add all your files to IPFS, through your local IPFS Desktop. Then, Fission's server will get sent the hash that represents the folder, we'll use IPFS to keep a copy of all your files, and update DNS of your subdomain.

The following command will be correct if you're on a Mac and downloaded to the standard downloads folder. Otherwise, just enter the path to where the unzipped Facebook folder is:

fission up ~/Downloads/facebook-YOURNAME/

I only had about 200MB of files, so this happened pretty quickly. Visit YOURNAME.fission.name in your browser and you should see something like this:

Your Facebook photos are online and browse-able! You can see mine at boris.fission.name/Photos/facebook (I put mine in a subfolder, because I already host a bunch of public files on my Fission site).

Technically the files are being served directly from your computer, when you're online and have IPFS Desktop running. The Fission service is also serving those files, and stays online when you're offline. As a next step, you can explore installing the IPFS Companion browser extension which will access IPFS content natively.

Join us in our Discord chat forum if you have questions or just come say "hi"!

Open Source Licensing Evolution at Diffusion 2019

Boris Mann — Mon, 04 Nov 2019 02:07:41 +0000

Boris gave this talk at Diffusion 2019 in Berlin.

The slides and links to licenses and other resources are available on Notist »