Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

The general idea is Layer 2s solve high gas. Most users will be using apps that run on a layer 2 and will make rare trips to the mainnet. The next thing being worked on is onboarding users direct to layer 2, and layer2 interoperability so you can move from one l2 to another

You can already use an L2 DEX to exchange tokens (and have been able to for about a year) https://exchange.loopring.io/

You can send L2 payments with https://zksync.io/

But those are limited to their applications. General purpose L2s arrive this month! with Optimism https://optimismpbc.medium.com/ and to be followed later this year by https://aztec.network/ and others.

With those we can redeploy code from mainnet to layer 2. With the apps on layer 2 the transaction fees will be fractions of cents and almost instant and a lot of the programs we have dreamed about but not been able to make become possible at scale.

Its an exciting time!



sort by: page size:

Can you elaborate on your perspective? I must admit that I don't use layer2 solutions and many people that think they are, are not (ie. users of Polygon's Proof of Stake network instead of their Plasma network), but I appreciate the progress on those layer2 solutions and actively support the bridges to them

this is a nice start. congrats i imagine v2 will have real-time connections to services that are mapped.

Layer (https://layer.com) San Francisco, CA

The Internet needs an open communications layer -- cross-platform and free from an advertising-supported business model. At Layer, we’re on a mission to deliver it. We’re hiring iOS, Android, backend, Web and systems engineers, as well as designers.

We have problems to solve that you’ll have a hard time finding elsewhere. Here’s why:

We’re building our own network. We need fine-grained control over latency and geographic distribution. We’ll be running our own AS (62862), peering at major exchanges, and purchasing transit from high-quality providers.

We’re running our own hardware. This goes to latency again: by owning our own routers, by being particular about what switches run behind them, and by provisioning memory and persistent storage specific to our application, we can deliver a better experience to our customers. We can also deliver at lower cost.

We’re designing our software for high availability. Losing a datacenter will not impact the availability of our service.

We’re building our mobile SDKs to provide a complete solution: offline message buffering, cross-device handling of push notifications, cross-device message sync, respectful battery consumption, and in front of it all, a simple api.

We care about documentation: https://layer.com/docs/ios. Our docs are the first experience developers will have with Layer.

We care about design. We won’t be releasing our own apps - that’s up to our customers - but we’ll be open sourcing beautiful example apps that build on our SDKs.

We care about security and privacy. Securing the transport is only the first step. When we don’t have the keys we can’t access the data. (In theory. Security is hard.)

Today we're a team of engineers and designers passionate about communications. We’re on a mission to make communications better through every product -- mobile or web -- that people use and love. We hold the power to dramatically improve the way 2 billion+ Internet users communicate.

We’re well funded and have already assembled an early team that shows we mean business. We’ve started and built world-class companies and highly scalable Internet infrastructure and invented protocols used by millions.

Get in touch: jobs at layer dot com


Also a dev on loki-network, we have $4.1+ million USD so far invested in relays (and potentially exits). It's layer 3 (so think more like i2p) but newer crypto and much better latency.

A good overview of the project is here: https://github.com/loki-project/loki-network/blob/master/doc...

other docs here: https://github.com/loki-project/loki-network/blob/master/doc...

Join our test-net now: https://discord.gg/eB8k6xQ or #llarp on freenode


The infrastructure layer is expanding, to meet the needs of the expanding infrastructure layer

very good point. maybe this is where service mesh (istio - envoy, linkerd) could be useful.

Ron Palmeri has a knack for picking great teams and ideas. The concept of an infrastructure that can later become the standard of communication is great with huge potentials.

Internet was built to be the standard of communication and I feel Layer takes that spirit a level higher to application infrastructure.

I wasn't able to figure out if there is a strong security play, especially in the current zeitgeist. They touched on doctor nurse communication so perhaps security is an adoption.


The article just discusses what the core team has been up to - it deliberately skips the wider community (for better or worse).

The youtube video at the end shows an alternative C2S and S2S transport being used - similar to the one described at https://fosdem.org/2019/schedule/event/matrix/. Atm it's experimental and only works in closed networks and isn't yet released, but the plan is to add it as an official alt transport once we've got it working nicely in open networks. It's about 30-50x more bandwidth efficient than the default HTTP/1.1+TLS+JSON transport.


Right now Flynn Layer 0 is very immature compared to Mesos, but yes they're trying to solve similar problems. After Flynn reaches production stability and builds out more features, we expect Layer 0 to be a valid (and much lighter weight) alternative to Mesos that we hope will be a superior solution for a broad class of users.

I feel like the projects have very different prospective user bases and communities (Mesos is an Apache project, hundreds of thousands of lines of C++; Flynn Layer 0 is run by a startup and only a few thousand lines of Go) and will likely develop in very different directions to service those communities.

That being said, we've explored creating a version of Flynn layer 1 components that run on Mesos instead of Flynn Layer 0 for users who are already deeply invested in the Mesos ecosystem.


With the activation of the Mumbai upgrade, Tezos now offers a unique and powerful layer 2 scalability solution thanks to Smart Optimistic Rollups. Functori is proud to be involved in this project.

Are there any plans for adding new transport protocols (for c2s and s2s communication other than HTTP)?

I didn't see Fractal being mentioned. IIRX they have received some founding from Puri.sm recently. Sorry if I messed it as I didn't read the entire article.


Nice. I have been toying in this space myself and programmatic alternatives to the existing solutions I think are the way forward.

The future features are exactly what I'm looking for. Namely simulcast support to help bandwidth limited clients and server scalability/redundancy especially in a WAN scenario.


wow news to me, wonder how long that will take to catch on

onion like "layered" services


Yeah there's definitely lots of internal discussion to see what can be done. Traefik is getting quite popular and is arguably the heir apparent. Nginx and HAProxy also work and are as battle tested as software comes.

We may also add a first class notion of ingress load balancing in the future and Envoy would be the natural choice there because we already use it for Nomad's Consul Connect integration.


We (cabal devs) have had many discussions about supporting i2p out of the box and this is a high priority in the project road map.

Thanks for your comment. I'm going to presume that this will be key to their SDN/OpenFlow developments? Is there any more publicly available information yet?

Touché. But the Omni Core Layer mentioned in the announcement implements them.

Thanks, many devs find themselves having to combine many integrations like this. We hope an open-source solution could be helpful.

We have the concept of Generic carrier that some of our users use to for LTL carriers without their own APIs. We are hoping to create a network like Convey but decentralized thanks to open-source.


Maybe not the same story, but there was a sidecar service for encrypting traffic and doing access control and other things in a way that was transparent to the app (like Envoy, but without the mesh and much earlier). The original version was written by (maybe) a single engineer in Erlang. Version two was given to another team and rewritten in Java because. They had never tested at scale and every team I know who went to production with it fell over. There was some company wide deadline, but it was unusable, at the point, and the teams I was working with were gun shy to try it again since it was obvious that the owning team had know idea what the performance characteristics or system requirements were for it.

I think I switched teams before that was resolved and moved to some greenfield work where we didn’t have to worry about scale for a while, but I do believe they eventually figure it out.

next

Legal | privacy