spolu

it works out of the box, tmate's servers are offline these days I believe. Also it's much simpler as it is not a fork of tmux; so you can run tmux in warp or warp in tmux.

It's a bit optimized for WKWebView for now... but not impossible to support android with a bit of work

Thanks! That's exactly what excites us as well and motivated us to work on this.

What message would you use on the landing page?

Completely understandable. There is no server, we don't store any data outside the app and the source code is available here https://github.com/spolu/dazzle

But of course this is Show HN material so still totally experimental.

Also there is no server. We don't store any data outside the app / your phone.

What about the shared tab/history concept?

Mostly a shared tab/history system that feel much more adapted to mobile. To a certain degree, access to everything without changing hand or an additional hand.

Under the hood there's only one WKWebview and that makes it feel surprinsingly I have to admit slightly faster.

Hi! That's fair. Pending terms of services; you have access to the source code here: https://github.com/spolu/dazzle

Of course; this is all very experimental for now.

PS: that's the whole point of a Show HN :-)

Hi HN!

I built dazzle with Antoine out of the frustration of having to use tabs on mobile. We wanted to explore a shared history/tabs mechanism that we expected to be particularly adapted to mobile usage.

After a few months of dog fooding we felt like it was time to share it publicly even if it's still a bit rough on the edges (and very experimental really).

Hope you have fun trying it, feedback welcome and encouraged.

There is a loading indicator at the bottom and you can go forward as well using the native wkwebview gesture.

We might add a force touch menu for reload, forward / back and share which is important if only for app "actions".

Interesting! add-ons are only available on Android right? Any feedback on the navigation UX, esp since firefox is very in your face when it comes to tabs?

Here's the link to the youtube video: https://www.youtube.com/watch?v=3zFrAxxlb-0

I'll also start by saying that I use less and less my mobile web browser since:

- many apps (like Facebook) do embed webviews that are now really powerful.

- I use the Gmail app for email, and a native app for most communication interactions (Slack, iMessage, Discord, etc...)

But yet I do often end-up using a web browser on my mobile pretty often (at least a couple times a day, if only to check HN or interact with Github) and I'm amazed how useless are tabs for me and how hard it is to find back content that I visited earlier. These are the two main pain points that I focused on initially and tried to solve with that first proof of concept.

For context, personal research project with an entirely functional implementation that you can try in under 2mn, see: https://settle.network/

Would love feedback on the model and ideas of where it could be made useful!

That's an interesting perspective indeed! This would alleviate the need to trust the reliability of the mint at least.

Hey! Very interesting work. I left a question below (above?).

I myself have been hacking on a payment related project which is also in "show" right now: https://news.ycombinator.com/item?id=13446587

Would love to get your feels as you've been thinking about machine-machine transactions quite a lot obviously.

Happy to discuss more over email as well.

Is there a cost to setting up a channel?

Could you elaborate what you have in mind?

A friend of mine shared this this morning right before I released the blog post (translated from French):

> It reminds me of the US before the introduction of the FED in 1913, each bank "issued" its own currency. Money was exchanged with a discount, as an example a bank in Chicago could accept money from JP Morgan in New York at a 50% discount. There were a lot of financial crisis, mostly because money was not elastic enough and the interest rates would skyrocket when everyone was asking money, which ruined mostly farmers. It does not apply direclty to Settle (anyone can issue IOUs) but it's probably worth looking into this"

Found it quite interesting, and worth sharing it here as well.

Just before I release that blog post, a friend of mine shared over email how banks before the FED was created used to issue their own currency in the US and how it led to recurrent financial crisis and skyrocketing interest rates that were eventually paid of by farmers.

He also mentioned that it does not necessarily apply to Settle (anyone can issue assets not necessarily banks) but I figured it was interesting enough to share it here.

Hack something cool and show it around.

The source code is available here: https://github.com/spolu/settle

A friend of mine shared this this morning right before I released the blog post (translated from French):

> It reminds me of the US before the introduction of the FED in 1913, each bank "issued" its own currency. Money was exchanged with a discount, as an example a bank in Chicago could accept money from JP Morgan in New York at a 50% discount. There were a lot of financial crisis, mostly because money was not elastic enough and the interest rates would skyrocket when everyone was asking money, which ruined mostly farmers. It does not apply direclty to Settle (anyone can issue IOUs) but it's probably worth looking into this"

Found it quite interesting, and worth sharing it here as well.

hahaha! Excellent remark, I didn't think of this one.

Following in up on this we just rolled out `application_fee` on the Order Pay endpoint (https://stripe.com/docs/api#pay_order).

It'll behave as expected if you're familiar with the connect `application_fee`.

Following in up on this we just rolled out `application_fee` on the Order Pay endpoint (https://stripe.com/docs/api#pay_order).

It'll behave as expected if you're familiar with the connect `application_fee`.

Thanks for the feedback and hope you'll make good use of it. Let us know how we can help with anything help!

(Stripe engineer here)

Running firefox as well and indeed they run a bit slow. Mea culpa. I'll let the right person know!

So this confirms the approach that we have in mind: the ability to setup a fee at order creation as it is the case in Connect (per charge there). Very :+1: on this.

(Hi Stripe Engineer here)

Relay is a way for merchants to route products to channels. We certainly don't want to replace Shopify (with whom we're pretty close) but just give merchants an easy way to expose product information to apps and accepts orders directly from there. In particular, Relay will not provide you with store front, or complex shipping and taxes calculations and integrations.

Ideally Relay should work seamlessly with Shopify, and Shopify users should be able to start selling on Twitter and other apps directly from Shopify through Relay without even necessarily hearing the name Relay (as it is ~the case with their payments currently processed by us)

(Stripe Engineer working on Relay here)

Indeed there is no way to do so at the moment. But we have that on our radar and we'd like to construct something that makes sense for apps and sellers.

Some questions related to that: How would you see it working? Isn't ads the new affiliation in the app world?

re Inventory: we want to provide live product availability information to the developer through our API. We encourage app developers to GET latest product info from our API before even rendering a potential Buy Now button. To make that possible we keep product information extra-fresh from big retailers, and even update it on the fly when we see orders failing because the product is out of stock.

re Payments/Processor: So that's where it gets interesting. We have constructed for Pinterest a full payment distribution infrastructure to send payment information securely to large retailers or their processors. This infrastructure will also be used by Relay. Doing so, we believe we bring a ton of value to the ecosystem. But I'm sure you agree with that given your focus!