DEV Community: Fleek

Introducing Fleek Machines (Early Access): One Click Verified and Private Compute

Fleek — Wed, 20 Nov 2024 19:43:21 +0000

Sign up today for early access to Fleek Machines

Fleek is excited to introduce the next iteration of our expanding TEE (trusted execution environment) capabilities: Fleek Machines. Fleek Machines are lightweight TEE VMs with docker support that offer builders a seamless way to leverage long-running (TEEs) for verifiable and/or confidential computing use cases.

Starting today, builders can request early access to Fleek Machines here.

Why Fleek Machines?

Here’s why builders should be excited about Fleek Machines:

One-Click Verified and Confidential Compute: Eliminate setup complexity. Simply deploy your Docker image, and Fleek Machines handles the rest.
Docker Support: Run anything in a TEE that you can run in Docker, making integration seamless.
No DevOps or Hardware Instantiation: Focus on your code instead of infrastructure. No more complex hardware or operational overhead.
Framework & Chain Agnostic: Fleek Machines work with all Web2 and Web3 frameworks, languages and protocols, making them a great fit for a variety of use cases.
Remote Attestation & Reproducible Builds: Verify execution with cryptographic proofs. Option to disable reproducible builds (useful for certain privacy use cases)
Reduced Time to Market & Costs: A faster and more affordable alternative to traditional TEE infrastructure options.
Unstoppable (Future): Plans to integrate into Fleek Network for enhanced performance (global edge deployments, geo-routing, redundancy) and security (trustless, permissionless, censorship-resistant, open source) in future updates.

Real Use Cases

Fleek Machines are already being tested by early adopters for different applications and use cases. Here are a few examples of some of the things builders are exploring:

1. AI Agent Hosting, Orchestration, & Processing

Whether you are creating chatbots, orchestrating a swarm of agents, building recommendation systems or automation tools, Fleek Machines deliver the devex, performance and integrity needed for AI-driven applications and use cases.

2. Privacy-Focused Consumer Experiences

Develop interactive privacy-focused consumer experiences where user trust is paramount. Fleek Machines enable secure processing of user data, meeting privacy and compliance requirements without sacrificing speed or performance.

3. TEE Co-Processor

Anything that’s too expensive to do onchain or too expensive for zk-proofs you could do in Fleek Machines and submit proof onchain (MEV, sequencing, rollup infra, oracles, heavy compute, etc.).

4. Compliance for Fintech and Regulated Industries

Fleek Machines simplify private computation with cryptographic proofs and verifiable execution. This makes it easier to meet compliance and regulatory standards (ex. GDPR) while maintaining scalability and performance.

The above examples are just the start. Fleek Machines are opening up new possibilities for verified and/or confidential compute use cases across industries and we’re inviting developers to be part of this journey.

Join the Fleek Machines Early Access Program

As part of the Early Access Program, you will have the opportunity to build, test, and shape the future of Fleek Machines. Participants will receive:

Direct Support: Work with Fleek’s engineering team to optimize your setup.
Roadmap Influence: Help shape features and capabilities to suit your needs.
Growth Opportunities: Showcase your work with case studies, blog posts, and more.

Ready to Build with Fleek Machines?

Apply for the Early Access Program and unlock the future of verifiable and confidential compute with Fleek Machines.

Button: Request Early Access [Link]

Let’s build the future of the web together. 🚀

Introducing Fullstack Next.js Support on Fleek: Build, Deploy, and Scale Dynamic Apps with Ease

Fleek — Mon, 04 Nov 2024 22:00:40 +0000

Today, we're excited to launch support for fullstack Next.js apps and sites on Fleek! With this release, developers can now effortlessly deploy apps and experience server-side rendering (SSR) and static site generation (SSG) functionality directly within Fleek's edge-optimized platform, unlocking unparalleled scalability, performance, and control.

Why Next.js on Fleek?

At Fleek, we’re committed to empowering developers with innovative tools that are reliable and cutting-edge. With our new Next.js support, deploying full-stack applications to Fleek has never been easier. Developers can now build apps and sites leveraging Fleek’s robust infrastructure coupled with Next.js’s powerful framework — simplifying the developer experience while optimizing for performance and cost.

Key Features in This Release

For this release, we’ve focused on the core features that developers require to build and scale Next.js apps seamlessly on Fleek. Here’s what’s available starting today:

App Router & Pages Router: Full compatibility with Next.js's app and page routing systems ensures that applications of any size can run smoothly on Fleek’s edge network.
Route Handlers: Define custom server-side route handlers for more flexibility in handling requests.
Dynamic Routes: Create dynamic routes within your app, enabling personalized content and advanced routing logic.
Static Site Generation (SSG): Pre-render pages at build time, optimizing load speeds and improving user experience.
Server-Side Rendering (SSR): Generate pages on request, ensuring content is always up-to-date without sacrificing performance.
Middleware: Run code before a request is completed, allowing you to handle redirects, authorization, and more, at the edge.

How to Get Started

Get started deploying a Next.js application on Fleek with the **fleek-next CLI** tool. Here are the steps to get your app or site up and running:

Install the Fleek CLI: Install the fleek-next package, a tailored CLI tool optimized for Fleek’s infrastructure. Simply run npm i @fleek-platform/next on your terminal.
Set Your Edge Runtime: In your server-side code, set export const runtime = 'edge'; to ensure compatibility with Fleek’s edge network.
Build: Use fleek-next build to build your application. If you’re working outside your project’s root directory, simply add the -p or --projectPath flag to specify your file path.
Deploy: Finally deploy your application using fleek functions deploy --bundle=false --path .fleek/dist/index.js --assets .fleek/static. This command will prompt you to add the function name, so ensure that you run fleek functions create -–name <function-name> beforehand.

For more details, check out the Getting Started Guide, GitHub, or Docs, or try the setup via NPM.

Looking Ahead

And this is just the beginning. Our Phase 2 release will bring even more power to Next.js apps on Fleek, including Incremental Static Regeneration (ISR), Image Optimization, Streaming Support, and more.

Here’s what’s coming:

Incremental Static Regeneration (ISR): Imagine the best of both worlds—high-speed static performance with real-time updates. ISR will allow your app to serve pre-rendered pages lightning-fast while staying fresh with the latest data on demand. No more full rebuilds; just seamless updates exactly when and where you need them.
Image Optimization: Fully optimized images, served at edge speed. Next.js on Fleek will handle image resizing, compression, and format conversion automatically, so your media-heavy apps load faster and look sharper. This means smoother UX and a boost in site performance across devices—your users will love it.
Streaming Support: With Streaming, Fleek takes your app’s interactivity to a new level, sending content to users as it’s generated. This opens the door to interactive experiences that load fast and keep audiences engaged, even with complex or data-rich applications.
Lazy Loading, Caching & More: Performance is a non-negotiable, and Fleek is working on bringing you even more control with fine-tuned caching strategies, lazy loading for route handlers enabling optimized page loads, and advanced edge configurations. These optimizations mean users won’t just experience your app—they’ll be immersed in it.

A New Era for Web Development on Fleek 🌐

At Fleek, our mission is to empower developers by creating open-source tools and infrastructure that enable you to build unstoppable and performant apps, without compromise. The addition of fullstack Next.js on Fleek represents another step toward that vision — unlocking access to dynamic content on an unstoppable, edge-optimized developer platform.

We believe in an internet where developers retain full control of their IP, non-negotiable performance, and an open-source codebase. By supporting Next.js with Fleek’s infrastructure, we’re enabling anyone to push the limits of what's possible in web development and create a new standard of accessibility, sovereignty, and transparency.

Our releases are a testament to our mission of advancing the open web and making powerful, open-source tools accessible to all builders, innovators, and dreamers. Join us in shaping the future of the internet—one open, unstoppable, and developer-first deployment at a time. We’d also like to give a special shout out to OpenNext, next-on-pages, and Vercel for enabling us to bring fullstack Next.js to Fleek.

Join the Fleek Community

Ready to explore Next.js on Fleek? Join our exclusive builder channel in Discord to share feedback, follow our updates on X, and don’t hesitate to show us what you’re cooking up. Together, we’re building the unstoppable future of the internet.

Get started building on Fleek:

Release Update - Fleek Hosting Now Uses IPNS for Updating ENS Domains!

Fleek — Tue, 01 Jun 2021 21:52:11 +0000

Hosting a site or app on IPFS with Fleek, and decentralizing its naming with an Ethereum Name Service (ENS) domain? Then this upgrade is for you. Now on Fleek, IPNS + ENS combine forces to make ENS IPFS hash record updates scalable, fast, and inexpensive on Fleek.

ENS Domains on Fleek

One of the first features we added to Fleek with IPFS hosting was using Ethereum Name Service (ENS) domain names through our platform. It’s just a dope combo. Distributed storage on one end, and decentralized naming on Ethereum on the other!

As a tl;dr of how they work in Fleek, when you deploy an IPFS site a content hash is created representing your site. This hash changes each time you make a new deployment, since it represents unique content.

How do we pair up your site with ENS? Each ENS domain name has a set of records you update referencing content. One of them is an contentHash, for IPFS/IPNS! Which you can use to point to specific data, or in our case, your site.

When you add an ENS domain through Fleek, you first trigger a transaction to give permission to Fleek to update this record, and then each time you make a deployment, Fleek updates the IPFS hash record on your ENS domain automatically in the background.

Each transaction requires a gas fee. Users only handle the first transaction (giving Fleek permissions), but all future transactions and record updates are covered by Fleek, costing the gas fee required to update the ENS record on the Ethereum network.

The Scalability & Gas Problem

We always double down on abstracting complicated steps to give dope Web3 experiences, and handling ENS transactions in the background is part of that motto. However, we can’t ignore the fact that both Fleek, and Ethereum, are scaling rapidly.

There were two main issues we needed to tackle. First, gas prices fluctuate constantly, and we’ve seen them go up and down dramatically. So, long term, we had to think about how to handle transactions seamlessly, at scale, without offloading it to the user, but also not becoming the living form of the “this is fine” meme.

Secondly, sometimes the time it takes for a transaction to go through can be variable, depending on the Ethereum network or fluctuating gas. We know how important for any web/app a push to prod can be, so keeping those times stable was also on our mind.

The Solution: IPNS + ENS

The core issue with ENS updates and transactions is the fact IPFS content hashes change on each deployment, therefore you need to switch that hash every time on your domain.

But, what if you had a different type of record on ENS, that doesn’t change on each deployment, but does reference a changing IPFS hash that you can update every time without having to trigger transactions on the Ethereum network?

That’s what IPNS essentially does for you on Fleek now! IPNS is the InterPlanetary Name System, by the awesome team at IPFS, which uses content-based addressing to create a static address that references a hash record that can be updated.

It is, in a nutshell, a public-private key pair. The name (IPNS address) is the public key, and it contains a record with a hash that is updated by signing and publishing the information with the private key. IPNS addresses are mapped in IPFS’ distributed hash tables (distributed system for mapping keys to values).

Instead of changing your IPFS hash on your ENS name, we can now set a static IPNS address, and make your IPFS hash updates in a layer 2-ish style.

This way we can reduce ENS transactions to just 1, without losing the distributed/decentralized perks of both IPFS & ENS. When a user adds an ENS domain, a transaction will be made to change the content hash of the ENS domain to the new IPNS address.

From that point forward, all future IPFS hash updates needed every time the user makes a change/deploy will be made on that site’s specific IPNS address record, at zero cost, and no need for gas. Scalable, fast, and cost-effective.

Does this change affect the experience in any way? Not at all. You won’t notice anything on the platform. If you are adding a new ENS domain, you’ll have to go through one transaction to change the record to your IPNS record, and that’ll be all. If you already have an ENS domain, on the next record hash update / deployment, Fleek will automatically switch to an IPNS record. This means Fleek won't be set as the controller anymore, since there is no longer need for it.

We will add the option for users to use ENS-only in the near future, for those users that want to continue using a dynamic IPFS hash on their ENS names instead, updating their hash upon each deployment and handling the transaction themselves.

Wrapping it up 🗞️

We’re so pumped about how the use of blockchain domains is ramping up. ENS usage alone on Fleek has been nothing but up since last year! And with this update we can ensure we can keep the pace up, and give all users the best experience possible for a long time.

Plus, the work put behind IPNS by the team at IPFS has been amazing! Since go-ipfs 0.5.0 resolving speed shot up by 30-40x and now MetaMask is also resolving its addresses. This, combined with ENS L2 (which we can’t wait to see more of!) will be key to scaling blockchain domains endlessly.

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Internet Computer Hosting - Now on Mainnet, Following the Network's Genesis!

Fleek — Fri, 21 May 2021 12:40:43 +0000

If you missed it (where were you!?), the DFINITY Foundation celebrated the final step towards the release of the Internet Computer’s public Mainnet network at the “Mercury Genesis Launch Event”.

Genesis is here. Which means the Internet Computer (IC) is being unleashed to the public! Hear us out: this is the start of a wild ride for the blockchain community and the future of the Open Web 🔥

Get ready, because not only are we are hooking up our Internet Computer hosting to Mainnet, and a lot of dope tech and deep dives were revealed on DFINITY’s event, but we’ve also got some new IC products cooking up that we will release later this month that are extremely dope.

A quick throwback + the Internet Computer’s Potential 🌀

A little over two month ago, we announced that we were going to Dfinity & Beyond! Joining the Internet Computer ecosystem with a bomb triple release (IC Static Site Hosting, Internet Computer Gateway, and Canister Proxying).

We announced this in the “Exploring Entrepreneurship in the Open Internet Boom” event, hosted by the DFINITY foundation (good place to start if you want to catch up with the Internet Computer!).

What does the Internet Computer mean for Fleek? It’s the missing link to materialize the Open Web. A trustless, decentralized, permissionless, and flexible infrastructure, and the next step for blockchain: fully-fledged, scalable, open internet services.

The Web2 is a wild array of corporate owned web services users don’t own or control. Its core infrastructure services like hosting, storage, and well, most web services, are centralized. In turn, everything built on the actual web is affected by centralized points of risks, gatekeepers, and general abuse by controllers.

Thanks to canisters, the Internet Computer’s equivalent to Smart Contracts (evolved to hold both state and program), anything can be built on an open, trustless, and decentralized internet infrastructure, governed by the Nervous Network System autonomous protocol. And when we say anything, we mean anything. Frontends, backends, databases, assets, infrastructure, Dapps, DeFi... All of them, living in an unstoppable infrastructure.

This means we can finally conceive open internet services. Imagine any service you know and use today (like hosting, storage, social media) but built as decentralized and user-controlled protocols anyone can access, governed by an autonomous network and its users, and not controlled or dependable on a few.

Basically, the benefits we’ve seen, for example, in Decentralized Finance (DeFi) & protocols like Uniswap on Ethereum, applied to the entire internet and its services, from back to front, and not limited to application logic only. Trustless logic, powering decentralized applications, surfaced in unstoppable frontends.

Fleek’s Internet Computer Hosting, Now on Mainnet 🚀

As of today, after a brief break in which the experimental Alpha Mainnet was disconnected as the DFINITY Foundation prepared for Genesis, all Internet Computer features in Fleek are back online, and connected to the Internet computer’s Mainnet.

You can now celebrate Genesis by hosting a static site through Fleek on the Internet Computer’s Mainnet! If you already had a site up on the Internet Computer with Fleek, hosted on the experimental Alpha Mainnet, you can retrigger its last deployment and it will be automatically pushed to Mainnet.

If you haven’t already, you can catch up with our documentation to learn how to. It takes 3 steps to hook up your repository with GitHub, set up your build settings, and get an unstoppable site up and running, which you can connect to a DNS or Handshake (HNS) domain. As easy as it gets.

What’s cooking behind curtains? 🥘

We don’t want to spoil it yet, but soon. Very soon. Like, a couple weeks max.

We have dropped a couple hints here and there, and Open Internet Services is definitely the main keyword to follow. We did share in past articles about where our goals were initially aimed, building and exploring the Internet Computer, and we can say that yeah, we’re following track, but there’s also a lot more that you still don’t know about.

How much more? It’s four different things to start: two Open Internet Services, a new IC specific developer platform for canister & cycle management, and an Internet Computer Provider.

These are not just things we’re talking about, we’ve been building them quietly behind the scenes for months and they are almost ready for launch!

That’s enough spoilers already.

We literally can’t wait, but we need to get back to work so that we can blow your mind away with it soon. On our roadmap to building the next web’s base layer of Open Internet Services, what’s coming next is a huge step in that direction.

Keep an eye out in the next couple of weeks, and in the meantime, start prepping some projects you want to take to the Internet Computer, because we’re gonna make it real easy for you to build amazing, seamless IC experiences.

Sign up to try Fleek
Join our Community Slack
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Troubleshooting Custom DNS Domains & DNS Configuration Upgrades

Fleek — Tue, 11 May 2021 16:19:06 +0000

Whether you are adding your custom DNS domain for the first time, or upgrading your previous configuration to Fleek's recent BunnyCDN upgrade, here are the most common questions/issues you might encounter and the answers to them:

I have a site with a custom DNS domain, and it is not working!

The first thing you can check is if your site is visible on the "Verify on IPFS" link on your Fleek dashboard. Visit your Fleek dashboard (the hosting tab) and select your affected site to find this button. See the gif below for a reference.

Can you access your site via the IPFS link? Then the most possible scenario is you're using our old DNS configuration and need to upgrade. Follow the steps on this documentation to update your domain records.

Another quick way for verifying if this is the problem is visiting the domain management tab on your site and seeing if the "Upgrade DNS Configuration" message is present.

If that is the case, you will need to set new ANAME/ALIAS records for your main root domain, and CNAME record for your subdomains. If you have DNSLINK activated, you will also need to update those records as well to the new configuration.

What type of records will I need to set on my DNS provider to use a custom domain?

You will need to set an ANAME/ALIAS record for the root domain, and CNAME records for your subdomains (www or other subdomains). If you have DNSLINK activated, it will also ask you to configure a CNAME record.

ANAME and ALIAS are interchangeable terms, and you might see one platform name the record either way. In both cases, it would work.

Can I set a custom domain using an IP address?

No, we no longer support configuring custom domains using IP addresses. We only work with ANAME/ALIAS and CNAME records. If you use Google Domains, there is an exception mentioned below.

Can I use an A record instead of ANAME/ALIAS?

No. A records are not the same as ANAME/ALIAS, and trying to configure your DNS domain with one will fail the verification process in Fleek.

What can I do if my provider doesn’t support ANAME/ALIAS records?

Some providers, like Google Domains and GoDaddy don't support ANAME/ALIAS records. You have two options to resolve this.

1) Transfer your domain to a compatible provider.

If your Domain Registrar / DNS provider doesn't support ANAME/ALIAS records, you can transfer your domain to a different platform that does support them. Some services facilitate this, like Namecheap. But the transfer process varies, and it can take time.

2) Change your domain's nameserver to Cloudflare. (Recommended)

This is our recommended solution. Instead of initiating a domain transfer process, you can instead change your domain's nameserver to point to Cloudflare and manage your DNS settings in Cloudflare.

Cloudflare supports ANAME/ALIAS records. They need to be set as CNAME in Cloudflare, but they are auto-detected, and work properly.

This doesn't require you to transfer your domain, it is quicker, and free.

How do I change my domain's nameserver and use Cloudflare to set up my Fleek DNS records?

First things first. You need to sign up for a free Cloudflare account.

Cloudflare provides a detailed guide on how to configure your nameserver on your other providers to point to Cloudflare. Here is a step-by-step guide, with specific guides for all different DNS provider platforms (see the table at the bottom of this article).

Once you have updated your domain's nameserver on your old provider to Cloudflare's, you can start managing your DNS records from the DNS app in your Cloudflare account. Here is a guide from Cloudflare on how to do so.

Ready to add your new Fleek DNS records in Cloudflare? There are two important details you need to follow:

ANAME/ALIAS records are set as CNAME on Cloudflare (Cloudflare will detect them)
When you set up a record on Cloudflare, disable the orange cloud (HTTP proxy).

It is important that you disable the Orange Cloud in all of the DNS records you set on Cloudflare for your Fleek sites/apps. If not, your custom domain will fail verification on Fleek. To turn it OFF, edit the record and click the orange cloud.

This is because when the orange cloud is ON, Cloudflare proxies your site through their CDN. Fleek already uses BunnyCDN to handle custom domains, and provide DDOS protection and CDN benefits in speed, caching, and routing. So they are not compatible, but you won't miss the benefits!

Remember to go back to Fleek after setting your DNS records on Cloudflare, and click on the "Verify DNS configuration button" for each of the domains you configured to complete the process. It might take a couple minutes for your site to reflect the change.

I set up my DNS records on Cloudflare, but it Fails verification?

Review the last step from the question above. It is important that you disable the orange cloud feature in Cloudflare's DNS app for all your Fleek DNS records. Fleek can't verify your domain if Cloudflare is proxying your domain to their CDN.

I use Google Domains, and don't want to have to use Cloudflare.

There is a workaround for people using Google Domains that don't want to use Cloudflare. This trick could apply to other providers that offer domain forwarding to sub domain from apex domain.

Here is a a detailed guide on how to do so. The idea is that Google Domains doesn't support ANAME/ALIAS records for apex domains (domain.com). But what you can do on Google Domains is forward that apex domain to a sub domain (www.domain.com).

In Fleek, subdomains use CNAME records, therefore you could verify it doing this trick, making www. your main point of entry for your website.

Still need help? ☎️

Tried everything above, and your domain still fails verification, or there is another error/issue that isn't solved by this guide?

Reach out to us through the Fleek' dashboard chat bubble, or join our public Slack and send a message in the support channel to share your issue. Make sure you have some screenshots and details ready, the team will be happy to help!

Release Update - New DNS Configuration with CDN Perks & DDOS Protection

Fleek — Tue, 11 May 2021 16:15:14 +0000

New upgrade coming for everyone hosting sites/apps on Fleek using custom DNS domains! You can now upgrade your site to our new DNS configuration to unlock extra CDN benefits, DDOS protection, and faster routing. Courtesy of Bunny CDN 😎

Our New DNS Configuration

We’re upgrading our custom DNS domain infrastructure to move away from HAProxy, and transition to using BunnyCDN so that we can supercharge all Fleek sites with extra CDN features, security, and a layer of redundancy when it comes to high-availability and 24/7 uptime.

The most important perks this change brings is adding a powerful and scalable anti-DDOS for all of our Fleek users, no matter their site’s size or plan, protecting their sites and apps automatically from all DDOS variants, without compromising their uptime or deliverability.

But, there's more perks other than security. Bunny expands our CDN perks with a redundant perma-cache layer that ensures, even in the worst scenarios, your site will be up and their files served in the most optimized way possible, re-routing requests in real-time to avoid downtimes or inefficient requests.

Expect faster, and meaner sites on Fleek, since every single one of them will be enhnanced with these CDN perks⚡

Important: This new DNS configuration requires ANAME record support by the DNS service/provider where you have acquired and manage your domain. Make sure it does so before migrating, or move to a new provider if necessary.

Migrating Your Site to the New DNS ⚡

If you already have a site on Fleek, you need to migrate it from the dashboard to the new DNS configuration to take advantage of these new features. It only takes a minute!

If you are hosting a new site or app on Fleek, you don’t have to do anything but configure your DNS domain when you create it, since this new infrastructure is now the default setup for all newly created sites.

This new DNS configuration will deprecate the previous one, and custom domains using the legacy proxy/DNS will stop working by May 31st. If your site is using a DNS custom domain, update its settings now to avoid any performance issues, and have your site continue to work after May 31st.

Migrating Your DNS Configuration

Log into your Fleek account, and do this for every site that uses a custom DNS domain. Visit the hosting tab, and click on a site on the list to get started.

Once inside a site's detail view, visit the SETTINGS tab and there, look for the Domain Management tab on the vertical sub-menu.

There, you will see the Custom Domains section, showing the Custom DNS Domain name you previously set up and connected to your Fleek site/app. Click on the "Upgrade DNS Configuration" button to re-configure your site.

In a nutshell, you will need to update your records on your DNS domain. This is because your custom domains needs to point to Fleek's new upgraded infrastructure.

Root domain names (like space.storage) will ask for an ANAME record, whereas any subdomain or www. domain (like www.space.storage) will use CNAME.

What about DNSLink domains? Those will continue to point to your Fleek-assigned subdomain using a CNAME record, so keep them that way for now.

Remember that to utilize this, it is required that your DNS provider supports ANAME records. Check this before starting the upgrade. In some providers like Cloudflare, ANAME records are set as CNAME, so do check first with your provider's documentation.

Once you have updated your record on your DNS provider, come back to Fleek to Verify the DNS Configuration. That is all! Your site will be updated to our new faster, and safer, DNS configuration.

Wrapping it Up 🗞️

That is all for today! This week we are taking extra care on strengthening and scaling our hosting features to give maximum reliability to all the amazing users coming into the platform. Expect more news on this soon!

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Release Update - Site Previews, Cancel & Retry Deploys, Table Improvements

Fleek — Fri, 30 Apr 2021 20:22:27 +0000

It's fixes and enhancements time ⚡ This week we're bringing another batch of updates that are focused on making your life a little better on Fleek. Most of these are user requests, so keep em' coming our way 🔥

What do we have in store this week?

Site Previews
Cancel & Retry Deployments
Storage & Hosting Table Fixes

New Features

Site Previews

First off, site previews have landed on our Hosting product. You've probably seen that when you navigate your site list and their settings, there is a small image box that was previously empty. Well now, upon each new deployment, Fleek will take a snapshot of your site and display it on that box as a site preview!

This way you can easily differentiate your sites/apps on the Hosting list, and have a clear visual confirmation of how your website looks currently.

Cancel & Retry Deployments

Because things can go wrong, and time shouldn't be wasted, we added cancel and retry buttons for your deployments on Fleek. If your deployment is stuck, queued in a series of other unnecessary ones, or simply anything went wrong with it, you can stop or retry it and start over. No more waiting for a timeout.

This was probably our most user-requested feature of all time! Better late than never right?

Enhancements

Hosting and Storage Tables

When you visit the hosting and storage section, the files you store or the sites/apps shown are listed in an infinite scroll table. Recently, some issues appeared in the table's loading animation and resizing. We've fixed those issues and improved the performance of both tables.

Wrapping it Up

That is all for today's release notes! Stay tuned for more updates and improvements coming later on next week. As always, you can hit us up in Twitter or Slack to let us know the features, improvements, or bugs you'd like to see tackled next 😎

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Release Update - Handshake Domains, Now Supported on Fleek!

Fleek — Mon, 29 Mar 2021 13:24:01 +0000

Fleek's protocol ranks grow again! Make room for Handshake, the peer-to-peer root naming system blockchain. Add custom HNS domains for both IPFS & Internet Computer hosted sites and apps, seamlessly, and as quick as it is to set up DNS or ENS.

Handshake and its thriving ecosystem & community blows us away each week with dope news like the release of dLinks by Namebase earlier this year or community projects like Flip.Flops, an email service on top of HNS!

We're pumped about welcoming this ecosystem into Fleek, and add another blockchain alternative to DNS, together with ENS (Ethereum Name Service), as they forge the road towards making unstoppable and user-owned naming a reality on the Open Web.

Plus, let's be honest. Owning top level domains is just cool and we can't wait to see what awesome domain+TLDs combos you bring on to Fleek.

Handshake & Namebase 🤝

A blockchain-based naming protocol / certificate authority, and a fire registry to compliment it. Name a better duo. If you haven't had the chance yet to know Handshake, it's time to catch up.

Our top picks for a quick start? HNS' documentation, learnhns.com, and The Shake.

In a nutshell, it acts like a decentralized extension of DNS' root zone file, where the ownership data of the web's TLDs are stored.

But with the added perk that it is done through a decentralized blockchain system that's permissionless and uncensorable. No middlemen or controllers. Domain buyers own the top level domains, and no entity (ICANN) could snatch it away or avoid the registration of weird & creative TLDs (.mars, .moonmoon, .whatever).

It's as if the current DNS registrar role was rethinked, and TLD owners in HNS would retake that role for themselves, each being the registrar of their own TLDs and doing with them as they see fit (commercialize domains, sell, transfer, etc), validated and backed by a blockchain network.

It's also backwards compatible with ICANN's root zone (.com, .org, etc.) to avoid conflicts with current DNS owners, who have their names and ownership reserved for their domains on HNS.

To top it all, HNS aims to peel off another important layer of trust/centralization of the web. Certificate authorities. Scrap centralized lists in hundreds of authorities for key authenticity verification (known to have gone rogue and compromised security in the past) and replace it with a decentralized blockchain-based and cryptographically-backed key verification.

Namebase on the other hand, is a parallel project, a seamless front for HNS, a registry and marketplace app where you can purchase, sell or trade domains on the HNS blockchain. It uses a simple bid/auction process for purchasing TLDs (emphasis on purchase, not rent).

You could operate and interact with Handshake directly via their native suite/node; Namebase is the abstraction of that process and a friendly web-platform alternative to installing a full Handshake node.

Using HNS Domains in Fleek ⚡

Recap aside, let's jump into HNS & Fleek! This will be short and quick, because adding HNS domains to your site on Fleek is as easy as it is to add ENS or DNS domains to any site. No surprises, and it is supported for both sites/apps hosted on IPFS or DFINITY's Internet Computer.

Once you have a site or app hosted on Fleek, you just need to visit the Domain Management Tab inside your site's settings to find HNS.

There, click Add HNS, and a modal will pop up where you'll be able to specify an HNS domain, and verify if it is owned already or available for purchase. If it's already owned, you just click Add Domain and you move on to the verification step.

How do you verify an HNS domain and link it to your site? Same way you do with DNS. Set up a custom record to point it to your Fleek site. If you use Namebase to get your HNS TLD/domain, you can quickly update your records through there, or use your own Handshake Nameserver as an alternative.

Hit verify HNS Configuration, and you're done 🚀 You've paired up Open Web hosting with a blockchain-based domain name.

Accessing HNS Domains

Handshake domains live on the Handshake blockchain, much like ENS names live on Ethereum, and are not yet fully supported/resolved but most browsers.

Still, while that gap is bridged, there are many ways of sites using HNS domains. The most quick and easy way is to use hns.to to quickly verify that your new site is up and running correctly. hns.to is a Handshake resolver, you can enter your domain in its search bar to find your site, or append its url at the end of your HNS domain name (my.site.hns.to ) to use it as a gateway to view it over HTTP.

Another option is to use an HNS compatible browser or extension, like PUMA, or the LinkFrame extension for Chrome, that

If you want, you can also change your devices' DNS to point to HNS resolving ones, like HDNS or NextDNS; you could even go all the way and install Handshake's node, hds to resolve their domains trustlessly and locally.

Without a doubt there's a ton of options, and if you need more you can peek at Namebase's guide, separated by technical level.

Wrapping it Up 🗞️

For us the main driving factor of Web3 is how open and collaborative and community-driven it is. The creativity engine of the Open Web is just on fire 24/7 🔥

To keep that engine fired, it's a must to keep integrating new protocols (like Handshake!) and helping to abstract and connect them to enable devs and users to easily explore the new internet's raw potential.

And Handshake's ecosystem packs a punch, we can't wait to see what new opportunities it opens up, and jam with the community on what could come next for HNS + Fleek. Feel free to pop into our Slack community and to brainstorm with the team on some ideas ⚡.

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Release Updates - Fleek Hosting CLI & API, and Github Actions

Fleek — Fri, 19 Mar 2021 18:13:17 +0000

Thought we'd take a break from news for a while after announcing trustless Static Frontend Hosting, a new Gateway, and Canister Proxying on the Internet Computer? Well, not today.

We keep updates coming 🔥 Today's release gives developers a lot more control over their experience in Fleek, especially over our Hosting suite of tools for building sites on the Open Web, and for integrating Fleek to other experiences:

Hosting CLI
GitHub Actions
Fleek's GraphQL API

The Hosting CLI 💻

We gave our CLI a power up, and now it includes our hosting pipeline! You can now interact with Fleek’s Hosting directly from command line, and try new cool workflow alternatives like:

Fleek site deployments from local machine.
Using custom GitHub actions or deploy from other CIs.

Everything is abstracted into just a couple of commands. Install, login, initialize, deploy, and you're done. Can't get any simpler. Want to get started with it? Here's all you need: CLI Documentation/Overview.

Unlike using our web app, when you deploy through the CLI, Fleek doesn't handle the build process, which simplifies the need of configuring build settings through the CLI itself. The workflow when using the CLI looks a little something like this:

Create a local repository.
Build your project locally.
Initialize your built repo directory on the CLI
Deploy your built site to Fleek through the CLI

Install the CLI:

npm install -g @fleekhq/fleek-cli

To confirm your installation, you can run fleek help\ which will show you a complete list of subcommands supported in the current version.

Login & Authenticate:

Next, you’ll need to login to the CLI using your credentials, to do that run the fleek login\ command and wait for a browser window to open, log in to your fleek account and the CLI will automatically store your authentication token.

To support flexibility each CLI command is categorized within a topic, for example, all of the functionalities related to the Fleek hosting are put together in the site\ topic. Each Fleek command has the following shape:

fleek [topic]:[subcommand] [options]

To get the help message dedicated to each topic just type fleek help [topic], which will show you a brief description of all the commands available in the topic.

Initializing a Site

One of the primary functions of the Fleek CLI is that it will give you the possibility to deploy websites from your local machine (or for that matter any environment other than our Fleek CI which currently works seamlessly with Github repositories).

Open your terminal, get to your built site/app's repository, and run the following command to initialize the site in Fleek, and configure it accordingly.

fleek site:init

A quick prompt in-terminal will guide you through creating or selecting a site from your Fleek account to initialize the proper settings on your local repository.

If all goes well, a .fleek.json file will be created in your local directory with the final site/Fleek configurations needed for the next step!

Deploying Your Site / Changes

You have your local built site, it is initialized and has its .fleek.json file. Now what?

Time to deploy! From terminal and the same local directory, run:

fleek site:deploy

And this would package the content in your local machine, and push it to the new site (or existing one) you selected from your Fleek account in the previous step

That's it! All you need to know to deploy a static site/app from your local machine.

GitHub Actions & Other Environments ✅

With the new CLI release, you can basically initialize and configure a built site/app repository to be deployed to Fleek; which, in concept, means you can handle that process from your end and then deploy to Fleek from other environments and CIs.

For example, doing it from your own GitHub CI workflow, using custom GitHub Actions!

Using GitHub Actions to Replace the CLI's Deploy

If you want to build and prepare your site locally or however you please, but still use GitHub as your CI, you can replace the need to use site:deploy in the CLI with a GitHub repo that has a Fleek-deploy GitHub Action.

You run the CLI's site:init call on a built repository to create the necessary .fleek.json config file.
The updated, built, and initialized code is then pushed to GitHub to reflect changes.
You will have a previously setup GitHub action that executes the equivalent of the CLI's site:deploy call.
Then, upon push or your set up trigger, the GitHub Action will deploy your site to Fleek.

*We already created a Deploy Action in the GitHub Marketplace *which you can use as is, or modified to add anything you need/want in your deployment workflow to Fleek.

View the repository above for detailed instructions on how to configure it with your API key.

Other Environments

Much like the example above, the CLI gives you the possibility of integrating other CI platforms other than GitHub or your local machine.

In a nutshell, this is possible because the CI enables you to prepare your Fleek site (initialize it) for deployment. Another important fact to enable other CI environments is that you can pass your API key as a Environment Variable:

FLEEK_API_KEY

This can be used as a substitute to the CLI's login flow, overriding the need for it, which would be a manual-browser flow that can't be carried out automatically by your CI of choice.

So instead, you pass the API as an environment variable, and that way you can execute all commands (site:init // site:deploy) on the command line without any breaking flows that require manual interventions.

The Fleek GraphQL API ⚙️

And if that wasn't enough, behind our CLI, and now also available as its very own thing, we have a new GraphQL Fleek API for our hosting suite of products! With all these tools, your hosting control room will be getting quite the upgrade 😎

This new simple GraphQL API is accessible via https://api.fleek.co/graphql

It exposes features to manage sites/hosting in Fleek, fetch data from them, and trigger new deployments. It requires an Hosting API Key to authenticate yourself, which you can now easily get through your account's settings.

Getting Started With the API

You can see and navigate the entire API's schema to learn all queries and mutations here. Right now it is an introduction to our hosting suite, and allows things like triggering deployments, retrying previous ones, query sites and site data (status and IPFS hash, for example), and query deployment statuses.

First things first, you need a Hosting API Key. To get it, visit your account's settings...

And generate a new key in the Hosting API Key module, you can do several if you want to separate them for different purposes.

And you're good to go! Authenticating is just passing the key in the Authorization heather request to auth your requests, for example authenticating a curl request...

curl -H "Authorization: <fleek-api-key===>" \
    -H "Content-Type: application/json" \
    -d '{"query": "{ __typename }"}}' \
    https://api.fleek.co/graphql

Most GraphQL client libraries let you add a header to all your requests, for example in JS with Apollo Boost:

import ApolloClient from 'apollo-boost';

const fleekApiKey = process.env.FLEEK_API_KEY;

const client = new ApolloClient({

    uri: 'https://api.fleek.co/graphql',

    fetch: fetch,

    headers: {

        authorization: fleekApiKey

    }

});

Query Example: Fetching Site & Publishment Details

You can find more examples on the API's documentation, this first snippet is an easy way to retrieve details from your published site on Fleek and its deployment.

query {

    getSiteBySlug(slug: "site-name-here") {

        id

        name

        platform

        publishedDeploy {

            id

            status

            ipfsHash

            log

            completedAt

        }

        team {

            id

            name

        }

    }

}

Wrapping Things Up 🗞️

This is just the beginning for these interfaces. So, hop on them and let us know what more things you'd like to see in the CLI/API. Our team will be on top of both projects to add more features and firepower soon, so that integrate Fleek into crazy new workflows and use cases, and platforms 🔥

On other news, we are joining Gitcoin Grants Round 9 Hackathon with Protocol Labs, Textile, IPFS, Filecoin, and a ton of more amazing Open Web projects!

Fleek's bounties are live, with three open tracks (Innovation, NFTs, Communication), for building Dapps using the Space SDK. Up for the challenge? ⚡⚡⚡

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

To DFINITY and Beyond: Static Front-end Hosting, Internet Computer Gateway, and the Next Steps.

Fleek — Tue, 09 Mar 2021 20:01:17 +0000

Major day for Fleek doesn’t begin to even cover it. Today, at a virtual event titled “Exploring Entrepreneurship in the Open Internet Boom” hosted by the DFINITY Foundation in partnership with Techcrunch, we are revealing that we are joining the Internet Computer ecosystem in full force and going live on the Internet Computer!

It’s a special release day — we have a series of new Internet Computer specific features coming out onto the Fleek platform, like Static Front-end Hosting!

This means you can now host and experiment with websites and apps on the Internet Computer's Alpha, a trustless blockchain-based infrastructure; as well as use our Internet Computer Gateway for accessing canisters over HTTP; or our Canister Proxying for resolving sites on the Internet Computer.

But we are also sharing our path forward on the Internet Computer, and into our idea of building a truly trustless, decentralized, and permissionless version of our Open Web services (e.g., hosting, storage, etc.) using Internet Computer canisters!

Buckle up, because when we say “To DFINITY and Beyond” we mean it.

New Features: Static Frontend Hosting on DFINITY's Internet Computer

As of this moment, you can take your static front-ends and host them on the Internet Computer with Fleek! In just a couple of clicks, you can move your site further into Web 3.0 by hosting it on a computational blockchain network growing to become the trustless base layer of the new web.

It’s as easy as it is to host any static site on IPFS with Fleek. You just need to:

Connect your GitHub
Pick a repository
Select Internet Computer
Configure, build, and deploy

That is all there is to it. Fleek abstracts the entire process for you. Canister creation, content updates, resolving, cycle management (though right now cycles are free-use on Mainnet, until they are fully implemented).

You can take any static site you used before in Fleek, and take it to the Internet Computer. All supported Jamstack sites on IPFS are fully working on the Internet Computer, and there is no change whatsoever in build settings or requirements.

Need help getting started? Visit our docs page!

You can build static frontends, which means either static websites as we mentioned, or Dapps or front-end apps that don’t require a back-end infrastructure and leverage instead APIs from the FE to implement services/features!

The Internet Computer's Alpha

It's important to note that this is an Alpha product, which we are launching and building on top of the Internet Computer's Alpha/Testnet. It is an experimental and early version that will help anyone test and build sites, apps or Dapps on the Internet Computer in preparation for the Mainnet Beta genesis!

Now's the time to test, experiment, and get your hands dirty building on the IC.

A minor limitation of this stage, for example, is a per-file size limit of 2MB, and a site/app total (for the entirety of the Canister) of about 2.5GB. This won't signify much on most static projects, but some media files (video/gifs/images) might be affected.

We'll progress the product as the Internet Computer progresses with the Mainnet, and once we reach the Mainnet's Beta, we will do a migration/redeployment of all sites to the Mainnet after Genesis arrives.

How Does Fleek Achieve Frontend Hosting on the Internet Computer?

The process in the background is straightforward. When you connect your repository to Fleek, and make a deployment, Fleek uses the DFINITY SDK (view documentation) to create a front-end Canister on mainnet, and build and deploy your website’s code to it.

Right now, we do front-end canisters only (thus, static sites), but in the future we will allow for back-end as well.

Then, the continuous deployment process begins! With your canister up and running, upon any pushed changes to your linked repository’s branch, Fleek will use the DFINITY SDK again to make Canister calls and update your website’s content reflecting changes immediately. This means you get all the usual perks, but with your site on the Internet Computer:

No content update delay
No risk of conflicts
Automatic SSL / DNS
CDN and caching

All these are considered, in many ways, Web 2.0 elements that act as a bridge between the now evolving Web 3.0. As resolving becomes native to more devices and platforms (like browsers, or native apps and Dapps), each will be replaced by its Web 3.0 alternative.

Domain Management and Resolving on the Internet Computer

When you deploy a new site on the Internet Computer with Fleek, a free generic preview link will be created, using Fleek’s Internet Computer Gateway and the your front-end Canister’s ID.

It will look something like this: [CANISTER_ID].ic.fleek.co

https://x4ytk-6yaaa-aaaab-qaiqq-cai.ic.fleek.co/

This URL is a direct HTTP access to your site/app on the Internet Computer! We’ll go into the Gateways detail on the next point. But, of course, we allow for custom DNS domains on the Internet Computer and the process is the same as it is with other environments.

Simply specify your custom domain, click verify DNS configuration, and add the appropriate record to your domain’s CNAME (instructions might vary according to your provider). Once all is set and done, you can click verify again (wait a couple minutes until it propagates) and your site will be up and running on your own custom domain.

What about blockchain domains like ENS (Ethereum Name Service) or HNS (Handshake)? We are working with all parties to combine the Internet Computer + Blockchain Domains, adding more and more options to peel off layers of centralization. We already have worked on experimental implementations, so expect news soon...

New Features: Fleek's Internet Computer Gateway.

There are two main things we had to address when tackling Internet Computer Hosting on Fleek. First, there isn’t a standard and quick way of accessing Canister data on the Internet Computer via HTTP, on the current web standards, without having to make actual Canister calls.

What’s more, this goes for all canisters and their data, not just FE canisters created by Fleek.

Secondly, we also have to consider that even if hosted on the Internet Computer, if we wanted to surface static sites from the IC on the current Web 2.0 we would need to handle basic concepts such as SSL, CDN, and DNS for our users.

Combine these two issues, and a little bit of radioactive open source code, and you get the reason why Fleek’s Gateway was born! Our very own transdimensional portal, (minus the disintegration-risk) that anyone, not just Fleek users, can use to access their Internet Computer-hosted Canister data over HTTP and an accessible URL format.

The Fleek Internet Computer Gateway lives on: ic.fleek.co

To access any canister, just add your canister ID before the URL , to get a url like this:

[CANISTER_ID].ic.fleek.co

For example, for this Create React App we mentioned above! https://x4ytk-6yaaa-aaaab-qaiqq-cai.ic.fleek.co/

New Features: Canister Proxying.

The Gateway itself as a proxy between users, and canisters on the Internet Computer. So, when it receives a request for a certain Canister ID, it translates that request, and the user receives the canister’s data through HTTP.

However, that is not all the Gateway does. Fleek’s Gateway gives users two Canister proxying options, or ways to connect visitors to your static site.

Using Fleek's seamless proxy (more centralized, but no loading state)
Using Fleek's service workers (less centralized, initial loading state)

Using Fleek as a Proxy

The default option is using Fleek as a proxy, meaning the initial request will hit our servers, translate the user’s request, and return the data from the canister to the visitor. This experience is just as any current website, seamless, but it does mean Fleek acts as a constant intermediary between the user and the Internet Computer.

This is also the default option for bots, crawlers, and extraterrestrial requests. For example, search engines and social crawlers. This way we ensure your static site on the Internet Computer is crawlable, indexed, and its metadata is readable by bots for important details like… Displaying Twitter cards, or images when sharing links on social!

Using Fleek's Service Workers

This alternative option is for users that want to further decentralize their experience, and connect their users directly to the Internet Computer. How does it work? If selected, only the first request will hit our Gateway, which will return a bootstrap script to the user, installing a Service Worker on their browser once, to connect them directly to the Internet Computer and retrieving all further requests directly from there, without having Fleek as a constant intermediary.

When you use the Service Workers option, a loading animation will appear once upon first visit (as the service worker is registered). All further visits are as seamless as the proxy, no loading screen, but without Fleek as a constant middleman.

Next Steps: Building Canister-based Services

Now, let’s switch gears from short-term to long-term planning. What’s the “Beyond” in “To DFINITY and Beyond”? For a while now, at Fleek we have been working on becoming an aggregator of the base layer of the Open Web, combining its protocols (Internet Computer, IPFS, Filecoin, Ethereum, Textile, GunDB, ENS, etc.) to create the bits and pieces that together form the base layer of web services that the new internet needs.

The piece that was always left hanging was the centralization and lack of trustlessness in the infrastructure behind the services we provide. An issue that even Dapps today face, while relying on things like AWS in spite of having a partially decentralized infrastructure powered on Ethereum.

It’s an element of trust that is hard to remove, but has to be removed at some point in time so that we can have the base infrastructure of the new web built on trustless and decentralized technologies.

Next Steps: Why do it on the Internet Computer

With DFINITY and the Internet Computer, we want to achieve that. It’s still pretty early, but V1 of this trustless hosting product is an amazing example of the steps we can take by combining a suite of tools built on IPFS, Filecoin, Ethereum, and so on, with a trustless infrastructure living on the Internet Computer’s blockchain network.

The Internet Computer, as a computational blockchain, provides us with the missing link. A computational blockchain with smart contract functionality, capable of powering and hosting web services in a trustless, permissionless, and decentralized way.

It’s like the benefits we see in using Ethereum for Dapps, but applied to the core of the web, which is its supporting infrastructure (hosting / storage / serverless functions / and so on..). All this, software logic, data,

So, the natural next step for us is to begin transitioning Fleek from a centralized infrastructure and product, to an Internet Computer, canister-based solution. Today, our IPFS hosting and storage, for example, relies on us running the infrastructure for it, and the interface itself is dependent on a Web 2.0 infrastructure.

By moving everything, procedurally to the Internet Computer in a canister-setup that’s open and entirely user-controlled, we can begin building the new set of canisters for web services (hosting, storage, auth…). Entirely trustless, community-managed, and permissionless.

For us the Internet Computer is an additive to all the protocols we currently work with, not at all a replacement. In concept it would allow us to take an element of trust (us running an IPFS-node infrastructure for storage and hosting) and build it decentralized, on top of the Internet Computer, so that our suite of services is not reliant on Web 2.0 infrastructure only we control.

It acts, in a way, as the base layer that ensures all other protocols we work with, and the features they provide, are built on top of and supported by an open network, and not closed or centralized providers.

We are on an exploratory phase, but in our history of combining Open Web protocols, we have found nothing but great use cases. IPFS and Filecoin set the groundwork for new distributed ways of handling storage and hosting; its content addressing and hash model is simply AMAZING.

Much like we combined IPFS and Filecoin in the past (when building Space, for example) to achieve things like user-controlled storage, but where users have Ethereum-based accounts, or can have web-based IPFS storage where keys are protected and decentralized thanks to GunDB.

We believe that marrying them both to the Internet Computer in the future, could open up amazing opportunities for creating performant and distributed content networks. A couple of things that we’re excited about is having dual-hosting, on IPFS and the Internet Computer, or on IPFS systems running on that network itself; which we are exploring.

Next Steps: Wrapping it up 🚀

This deep dive into the Internet Computer's Alpha, and first batch of releases in Fleek features for it has helped us get our hands dirty, and really understand the potential behind the Internet Computer and what it could mean for the Open Web.

We’re pumped and as confident as ever, that reaching fully decentralized, trustless, and user-controlled services is not only possible, but the technology for it is already here, peeling off a bazillion of the remaining trust layers that today affect web services, Dapps, and more complex platforms that can’t be fully decentralized yet because they rely on services like AWS.

It’s month 3 on the year, and we have already announced Space, the Space SDK, Filecoin Archiving, Fleek Storage V2, and now our first steps onto the Internet Computer, and a future transition to a decentralized and user-controlled version of our platform that looks as bright as ever.

We told you 2021 in the Open Web was going to be AWESOME 🔥

So stay posted, because we’re bringing more updates soon, and we are not thinking about slowing down our pace with these kinds of surprises!

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Filecoin Archiving Comes to Fleek Sites and Storage

Fleek — Fri, 19 Feb 2021 12:57:32 +0000

Another update incoming! Last time, we announced the release of the Space SDK, our new open source library. Today, we’re excited to announce we’re enabling automated Filecoin archiving / backups for all sites and storage on Fleek.

That’s right. We’re adding Filecoin as an archiving storage layer, and everyone using Fleek right now will benefit from it right away, no extra cost involved and available for all.

That means that if you have a website running on IPFS with Fleek or store files on IPFS with us, no matter your plan, then you'll benefit from having them backed up on a decentralized storage network, taking your project even further into the Web 3.0!

Why Filecoin Archiving?

Filecoin released its Mainnet last year, on October the 15th, and since then it has hit milestone after milestone, already surpassing 1 Exbibyte (EiB) of decentralized storage capacity and ending the year at a high note.

We crossed paths with the team behind Filecoin and IPFS, Protocol Labs, and have since then aligned our efforts in building the necessary blocks that will make the Web 3.0 not only a possibility, but a robust one.

Storage is one of those blocks. As of today, storage is one of the most centralized core aspects of the current web’s infrastructure, and peeling that centralization layer off is not an easy feat.

Not only storage is controlled by a handful of online providers, but the actual files themselves are stored in a centralized server infrastructure. One mistake, and things like AWS’s outage last November occur, taking a chunk of the web down.

The path towards solving this, and the one we are taking with Space and Fleek, is a procedural one. First, we shifted the storage paradigm by offering distributed storage on IPFS that users control.

That was the first step, rebuilding storage around the user, not us. IPFS and Textile allowed that by helping us design a hosted infrastructure that gives users sole control over the keys to the files/data, while also benefiting from the perks and security of having their files pinned redundantly in a distributed storage network.

However, there is still a layer of trust in that we help run IPFS nodes. So, naturally, the next step to this procedural process is to peel off that layer.

Filecoin allows us to begin peeling off that infrastructure centralization layer by offering backups and archives that reside in a decentralized and open storage network whose existence doesn’t depend or rely on us as a company/platform.

Filecoin in Fleek V1: Archiving

In this first V1, Filecoin will work as a secondary archiving layer that is parallel to our main IPFS storage infrastructure. Why not replace our entire storage with it? Because Filecoin’s purpose is different from IPFS in its current state, though it will continue to evolve to eventually replace it in the future.

IPFS provides us with a performant and distributed user-controlled storage layer, ideal for day-to-day performance-heavy content operations; whereas Filecoin’s current state is built to provide a robust and trustless archiving layer that does an amazing job at ensuring the integrity, longevity, and persistence of your files and data. Think of it as Filecoin being your cold storage layer, while IPFS is the hot/warm one.

This is just the beginning, though! As Filecoin grows both its network and functionality to match, surpass, and complement IPFS in features, we expect to continue transitioning more and more of our storage infrastructure to it and enable other use cases using it.

A Snapshot of the Process

Now, let’s dive into how Filecoin archiving behaves in this first release. When you upload a file or host a site on IPFS, Fleek will begin to package them into batches and ready them to be stored in Filecoin.

These payloads (composed by multiple files, not individual ones) are then sent to a Filecoin miners who receive the pieces of data, prompting a deal on chain, and beginning Filecoin’s “sector sealing” process. Here the miner generates a proof-of-replication, a unique representation and replica of the data, sealed in the storage “sector” after being encoded into a new configuration that allows for the next proof process (PoS).

After this, miners must constantly present a Proof-of-Spacetime, or proof of the continuous storage of this information.

And thus, your files and data from Fleek are archived in Filecoin! If you access your Fleek account and navigate to a live site, or to a file in your storage, you will be able to see the corresponding deal ID for the Filecoin transaction confirming it is archived in the network. When your file is scheduled but hasn't been archived yet, you will see a pending state.

In V1, Fleek interacts as with the Filecoin network on behalf of users to generate these data payloads and ensure the viability of the process; we expect to see this framework changing as Filecoin does as well, enabling per-file dynamics in the archiving/retrieval process, and the direct interaction of our users with the network.

It’s Just Getting Started.

Above all, we’re thrilled! These first live interactions between Fleek and the Filecoin network give us a moving picture of what leveraging decentralized and open storage networks looks like from a platform/app perspective.

The groundwork is set, and the first of many steps has been taken. Now, it’s a matter of growing side by side with Filecoin, and continuing to enable more and more use cases to the public! For example, using Filecoin as a decentralized backup layer for personal storage, in Space, which is going to support it on-launch.

Thanks to the team at Protocol Labs for the amazing work together these past few months, and we’ve got nothing but high hopes for what’s coming next!

And do stay alert for that, because like we said, this is just the beginning. We are two months into the year and we can say that, without a doubt, it will be jam-packed with news from IPFS, Filecoin, us, and the rest of the Open Web community.

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co

Introducing the Space SDK: Build Your Web & Mobile App on the Open Web

Fleek — Wed, 03 Feb 2021 12:36:20 +0000

The team’s thrilled to showcase our latest open source endeavor… A new library for developing decentralized applications on web and mobile: the Space SDK!

The Space SDK is a JavaScript/TypeScript library that you can integrate with your website or mobile application to enable them to store files in a user-owned way on the distributed web (IPFS/Textile nodes), and easily access to more Web 3.0 protocols via an implementation of the Space API.

You can find the repository and documentation here:

This is an early version of the SDK, and more updates are coming to it this week as its first expansion (Sharing features), as well as in the upcoming months as we test it out in the open and receive feedback and suggestions to explore new ideas!

The Space SDK is a complimentary framework that enables the use of IPFS, Textile, Ethereum, GunDB, and other Open Web protocols via the Space API, without the need of running local instances like an IPFS node on the user’s device, and allowing for web and mobile experiences that can:

Store files and data in user-controlled storage.
Enable public or private and e2e encrypted file sharing.
Integrate a user-owned key-pair based identity system.
Host/deliver content via user-powered global data layers (coming soon!)

All features in the Space SDK are simplified. Things like storage, file sharing, key-based authentication are easily accessible via ready-to-use methods 🔥

Unlike the Space Daemon, the Space SDK is modular and protocol agnostic. Each module can be customized, meaning, you can take advantage of each module as it is with the protocols/connections we provide, use it as a framework to plug in your own implementations, or replace a piece altogether!

For example, instead of using the default connection to the Textile hub on the Storage module, you can replace it with your own storage layer -for example, Hypercore- and still be able to work with the rest of the SDK’s functionalities.

That’s how we built the Space SDK: flexible, light, and as mobile and web friendly as possible.

Different needs, the same perks

If you recall, earlier last year, we released the Space Daemon, a library for desktop that comes with IPFS/Textile nodes, exposed gRPC methods for features like encrypted file upload, file sharing, user-controlled accounts, and more tools for building Open Web applications, under the same underlying protocols.

Today, the Space SDK arrives to make all of these features readily available on web/mobile.

The main difference between the two, aside from the fact the SDK is built on JavaScript while the Space Daemon is built on GoLang, is that the Space Daemon embeds an IPFS/Textile node and caches files there, while the SDK only uses GunDB’s decentralized database for storing file/bucket metadata and keys, and relies on the remote Textile Hub for distributed online storage.

This switch comes with a great perk. Not only can web/ mobile apps can access Space’s distributed storage network. But, in the future, we expect to open up Space so that our users, and any other platform and their users, can host and deliver content via Space’s open storage layer.

This is one of many stops on our exploration of ways to provide an interface for decentralized storage for both users, and platforms, so stay tuned as we bring more updates later on this year.

Features Under the Hood

The Space SDK continues the trend of letting applications distribute their storage, and give users true ownership over their accounts and data. From user-controlled storage and key management, to end-to-end encrypted file sharing and interactions powered by Open Web protocols.

Most features available in the Space Daemon are available in the Space SDK, and those that are not will be added soon, like Sharing!

These methods are accessible via different interfaces, which are easily replaceable or reconfigured if you want to use your own storage/auth/identity/etc layer.

Currently, the SDK has the following APIs:

Users API:

The User Module handles a couple of elements regarding user identity and authentication management. The default implementation provides a basic identity layer on top of the Textile Hub, handling key generation and retrieval for each user, authentication, and session tokens.

Identity creation and management
Challenge-based authentication
Passphrase key backup

Storage API:

The Storage Module enables web/mobile applications to upload, pin, manage, and fetch files and data from IPFS/Textile, programmatically, using CRUD operations. By default, it points to the Textile Hub and Space Services, but it can be modified to connect other storage layers. GunDB is used as the default metadata storage used by the UserStorage class.

Create files / directories
List files /directories
Create buckets
Sharing (coming soon!)

Interface Highlights ✨

We already went under the hood to see the features the modules/APIs enable, now let's dig a layer deeper and highlight some useful interfaces that are behind those features! You can see all interfaces in the package breakdown here.

For example, the Vault interface, used by the Users API to store and retrieve sensitive credentials in a secure and encrypted way.

Or the UserMetadataStore, that includes all actions to create, update, and retrieve user Bucket metadata records.

Getting Started: Installation

Installing the Space SDK is extremely quick and easy. Just use the following npm command to install the library and get started:

npm install @spacehq/sdk

That's all! You're set to get started using our different APIs.

Users / Identities example:

import { Users } from '@spacehq/sdk';

const users = new Users({ endpoint: 'wss://auth-dev.space.storage' });

// createIdentity generate a random keypair identity
const identity = await users.createIdentity();

// the new keypair can be used to authenticate a new user
// `users.authenticate()` generates hub API session tokens for the keypair identity.
const user = await users.authenticate(identity);
// `user` can be used with the storage class to provide identity.

// user's identity can also be backed up with a special recovery phrase
const uuid = 'specify-uuid-representing-user-in-your-system';
const passphrase = 'specify-unique-pass-phrase-related-to-backup-type';
const backupType = VaultBackupType.Google;
await users.backupKeysByPassphrase(uuid, passphrase, backupType, user.identity);

// backed up users identity can also be recovered later
const recoveredUser = await users.recoverKeysByPassphrase(uuid, passphrase, backupType);
// `recoveredUser` has same authentication as `user` above.

Want more examples? Read the User's class document.

Storage example:

import { UserStorage, AddItemsResultSummary } from '@spacehq/sdk';

const storage = new UserStorage(user);
await storage.createFolder({ bucket: 'personal', path: 'topFolder' });
const result = await storage.listDirectory({ path: '' });
// result contains `topFolder` items

// upload a file
const uploadResponse = await spaceStorage.addItems({
   bucket: 'personal',
   files: [
     {
       path: 'file.txt',
       content: '',
     },
     {
       path: 'space.png',
       content: '',
     }
   ],
});
// uploadresponse is an event listener
uploadResponse.once('done', (data: AddItemsEventData) => {
  const summary = data as AddItemsResultSummary;
  // returns a summary of all files and their upload status
});

Want more examples on storage? Read the Storage API's documentation.

Open Source and Collaborative

The Space SDK is an open source community endeavor. Every module in it is open for developers to build with, expand, and explore without limits, and we will continue to develop it hand in hand with the community!

We think the path forward to the distributed/decentralized web is open source and collaborative, and that is why we’re building the Space SDK as a modular and flexible set of tools that are not bound to a single use case or the current Open Web stack.

Start Building, and Share With Us

You can get started with the Space SDK on its Github page, and join our Developer Community in Slack to share your project or chat with the team if you have any questions/suggestions.

We’re looking forward to seeing what cool projects come up! It’s exciting to think that, with the SDK, Dapps and websites across all platforms (web/mobile/desktop) can explore new ways of providing Web3 enabled features 🔥

Sign up to try Fleek
Join our Community Chat
Follow us on Twitter
Subscribe to our Youtube channel
Check out our Tech Docs
Contact us at support@fleek.co