spolu

Very thoughtful analysis! (Stripe engineer working on Relay here)

Getting retailers on-board is definitely core to the success of Relay. As announced today Saks and the SAP Hybris platform are live on Relay and we're working with numerous other retailers as we speak.

For apps, getting retailers to sell on their platform is a huge pain (custom integration to their APIs and payment systems) convincing them to do so. For retailers as well it's a pain. They have to create technical integrations with as many channel out there. That's why we think Relay make sense. We help both side of the equation.

Also, the relationship between a retailer and a channel app in Relay is opt-in today. This is literally a Stripe Connect (think OAuth) connection. But once a channel is onboard, it's nothing more than clicking a button for a Relay retailer to start selling there.

Also I wouldn't say they are losing control on the full shopping experience, they're merely enabling a better one on mobile. When you think of the shopping experience, a lot happen after the purchase (support, shipping, loyalty) as well and I think there are new experiences to create there, especially once the customer receive the receipt from the retailer.

Feel free to repost your comment here!

Hi! Stripe engineer here. On Apple apps, if you're integrating Relay, you're encouraged to use Apple Pay for seamless transactions! Apple is perfectly fine with that if this is not an in-app virtual good purchase.

Also as pointed earlier Patrick (pc on HN) != Twitter CEO :)

> "It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection".

Failing to ensure quorum intersection in my quorum slices choice will have local repercussion and may befoul nodes that depend on me but does not prevent global functioning if the rest of the topology has quorum intersection.

I think your argument here is sane, but I also believe that under reasonable circumstance we can expect the Stellar network to be well structured. Yes some edge nodes may get befouled as you would in real life if you would trust an untrustworthy bank or health insurance.

Well in bitcoin, of course, trust would map to computing power.

I think this page should answer your questions: https://medium.com/a-stellar-journey/on-worldwide-consensus-...

(disclaimer: I had early access to the white paper for review)

Sybil attacks are not really directly applicable here since each node in the system picks its own quorum slices (basically the set of nodes that it trusts). There is no notion of global reputation and nodes do not need to know every other nodes to participate. Looking at the definition of quorum intersection[0] section 4.1 should give you a sense of the conditions that are required on the choice of quorum slices for the network to function properly (quorum intersection ensures safety)

The proof exposed in the paper guarantees safety and liveness for the network provided a certain number of reasonable conditions are held true. What that means is that an attacker cannot force on intact nodes (definition p14) invalid transactions nor prevent the network from making progress.

That being said, (at least in the version I reviewed) there is no guarantee provided with respect to ensuring that all valid transaction will eventually make it into the network. Indeed a set of highly trusted nodes (present in a lot of quorum slices) could attempt to preempt a specific set of transactions X (originated by edge nodes) by opportunistically broadcasting valid transaction set V_i for each successive ledger entry i that explicitly do not include the targeted set of transactions X. Under raw SCP as described in the paper and for certain topologies this preemption could be real and this is the closest I can think of a Sybil attack. It's important to note that we still have liveness and safety in that case.

I believe the same kind of attacks to be plausible with the Bitcoin network and I know protection mechanisms against it are currently being evaluated by David, Jed and the rest of the team. I will let them share their progress when they think it's right. I also hope they will correct me if I stated anything inaccurate here!

[0] https://www.stellar.org/papers/stellar-consensus-protocol.pd...

(disclaimer: I had early access to the whitepaper for review)

You should look in the white paper[0] to the definition of an FBAS which differs from epaxos (while epaxos is egalitarian, SCP is federated). All related proofs are included in the whitepaper, the central one being theorem 3 in 4.2. Finally the protocol specification (Figure 15, p28) is also very interesting.

[0] https://www.stellar.org/papers/stellar-consensus-protocol.pd...

Really cool execution. Love the cyphertext view. The key exchange seems a little non-secure given the length of the sharing URL?

How does it work?

The story behind this project is awesome. Built by the team behind AppGratis which got huge and was then shut down by Apple. They're now back full steam with this project.

The story behind the service is definitely interesting. Made by the team behind AppGratis which was huge at some point but were shut down by Apple.

This the most extreme Gist I have ever seen. So fun to see a functional browser implemented with only a few lines of code.

Disclaimer, I'm on of the dev being Thrust. That's exactly why we built Thrust, but @morganrallen pushed the envelope by distributing that through a Gist. So cool.

Well it's handled by Node directly right?

It can be binded in C++ yes

Yes exactly. I started coding in Python 2 days ago so I went with what I found (asyncio) but it could be easily recoded in Python2!

Only this one is not designed by you...

Additionaly it's much easier to use native modules! No recompile needed

Distribution through npm directly. X-language also.

Make sense?

pip or npm yes!

The only browser that fits in a gist!

Screenshot from a remote server running on AWS. I guess the settings are screwed up on that machine!

Quick note on comparison with node-webkit / atom-shell:

node-webkit and atom-shell embeds NodeJS along the chromium content module forcing its user to use not only NodeJS but a particular build of it.

On the contrary, Thrust embeds the Chromium content module and exposes an API on the standard IO, which makes it bindable in any language and works perfectly well as a dependency with vanilla nodeJS / Go / Python

Makes the distribution of cross-platform GUI apps through the pip/npm possible.

sure no problem

Hey, how come this is not yet on the homepage? my last post is weirdly stuck in newest as well... Any pb with the posts are picked up for homepage?

CEF is packaged as a library that requires embedding in your final app. The standard IO API of Thrust makes it much more leightweight to embed and distribute.

node-webkit and atom-shell both embed a version of NodeJS along the chromium content module. As a result, their are usable only from NodeJS and create complexities when requiring native packages (these package need to be recompiled using the special nodeJS image)

On the contrary, Thrust exposes a standard IO API that is bindable from any language. Right now there are bindings for NodeJS, Go and Python. As a result these libraries are simply requireable or importable and can run with vaniall NodeJS/Go/Python.

We designed these libraries so that at post_install, a binary version of Thrust is downloaded automatically which makes apps based on Thrust distributable through the native package manager.

These are the two advantages that motivated Thrust vs atom-shell or node-webkit.

It would be even more awesome it it was collborative with other people logged onto the website!

Quite addictive indeed. Love the gameplay.

Also that would mean training? Which is rather cumbersome here. Can you elaborate a little more ?

Nice write-up! Very interesting.