The (non-)existing problem with interactive transactions & UX - Rant

So you think the combination of those 4 points would bring people in? Could be, i just don’t think it’s good enough to make people change for the reasons i’ve mentioned above. I’m not saying ITX would bring them over though, just that they offer something unique, so if the market would need this, then their only option would be grin. But it’s possible that the market won’t care about this, who knows. I’ve mentioned why each of those 4 bullet points wouldn’t bring people in, where and why do you think i’m wrong there?

1 Like

Based on your arguments, you seem to think Grin will never offer enough to bring people over, so the best we can do is capture a small audience by filling the ITX niche. While you may be correct, most of us were never interested in having Grin fill a tiny niche. If you feel its only usefulness is for a few very specific needs (which are still possible even if we offer NITX as an option), and that it will never meet its goal:

  • Electronic transactions for all. Without censorship or restrictions.

then you should first focus on changing our mission statement to see if others agree.

However, if our mission statement remains “electronic transactions for all”, then it’s undeniable that ITX hurts that, since it makes electronic transactions more difficult to perform.

P.S. I hate having this stupid argument so f*cking much. Can’t you just agree ITX sucks for most cases, but we’re stuck with them? Please stop pretending like ITX are actually great for Grin, so I don’t have to keep calling out that obvious bullshit.

1 Like

For anyone new (or any future Grinners, hello!), there’s also a thread that tries to describe the differences between these transaction creation methods Transaction Interactivity Levels.

3 Likes

From your various postings it seems like you believe the primary factor in Grin having few users(low price) is, because, of it’s high inflation rate and that you can’t understand why anyone would hold Grin and that people who hold Grin must be silly crazy risk takers who obviously don’t understand inflation. Tbh I find this to be a narrow minded perspective.

I’d argue that Grin’s high inflation rate is factor, however, it’s not the primary factor in Grin’s current price or in preventing adoption.

High inflation rate ≠ price must go down.
High inflation rate = more demand is required for price to go up vs low a inflation rate

People = Avg crypto hodler

People care about scalability(TPS) but not tx/ chain size/ IBD. People like knowing that their coin has the ability to support mass adoption in the future( Ability to spend in the future) So with no Grin lighting network in production we’re already at a disadvantage vs BTC. This hurts demand.

In terms of privacy, it doesn’t matter what you personally think, it’s what the market aka the people think and at the moment people are convinced that Grin’s privacy is broken. Which it is vs Zcash/ Beam/ Monero, because, of no meaningful tx graph obfuscation. So until this is improved then privacy is never going to be good enough for people, which hurts Grin’s use case(demand) as an alternative currency.

ITX might not be enough to bring people over, however, it would become easier to onboard new users and improves Grin’s UX/UI, making it more spendable as a currency. Exchanges/ mining pool would appreciate it as well.

At present, why should new users bother to learn a new/ less convenient tx method vs other competing coins, when Grin currently offers them less value vs other competing coins? Less scalability( TPS), less privacy, less liquidity, less use cases. There’s no incentive for ITX.

If Grin already had a lighting network then the argument for ITX would be much stronger imo.

2 Likes

It would be cool to have some trustless p2p cache that could store encrypted slatepacks for certain number of hours until recipient gets online and picks them up. Some sort of special type set of nodes that would get paid in ツ for providing such service.

4 Likes

I understand why people hold grin, i don’t understand why people are surprised about its price in 2021. So no, grin holding doesn’t seem stupid to me, it just seems to me like high risk high reward but people expect reward too soon

The way i see it is that high inflation rate = more demand is required for price to not go down since miners will probably be selling a lot when inflation rate is high (you can always find holders ofc). So my expectations are that it can have huge spikes in price, but it should come back down until inflation rate is lower

Probably meant to say NITX, i agree it makes onboarding easier for users and exchanges. Although to be fair I’ve never come across an itx explanation for regular users. But nitx will always be simpler, i don’t deny that

I don’t think having nitx would fix those things, rather i think itx give us some new use cases (hard to say whether the market needs that or not)

If grin’s goal is electronic pay system then we definitely need L2 for that since grin’s L1 scaling requires less space to run a fully verifying node but its finalization is 1min which is way too slow for that. So i hope grin gets lightning one day

That’s a nice idea, i think they should get fees for storing each slatepack

2 Likes

Hi Elwailly, can you please explain to me why you do not use or want to use interactive transaction? E.g. what is the use-case scenario(s) that causes problems for you, what wallet software do you use?
E.g.
a) you want to transfer to a friend but he is ofline,
b) you want to transfer, but you have to do all that extra work with copying slatepacks?
c) …

I am asking because I think to improve the user experience for Grin we need to get to the root cause of user problems. We have to think in use-cases instead of technology.
E.g. I for do not really care about my Grin transactions being interactive or not since if I send to another wallet that is online, it is one click in Grin++. In other words, for my specific use case it is completely irrelevant what magic happens under the hood since it just works. I know that others might have uses-cases where interactivity might be more of an obstacle, hence I want to know/collect these use cases so we can discuss these problems as well as solutions from a technologically agnostic point of view.

Use Case 1: Venmo/Cash App experience

statement: As a friend, I want to fulfil an IOU of my other friend at their and my convenience.

Have you used Venmo or Cash app before?

There certainly are scenarios in which payments are made in an “interactive” manner. Like one friend scans the other’s QR code.

But in most cases, payments are sent after the fact. After dinner, the next day, etc. And this is simply impossible to coordinate in an interactive manner. One person is hungover, one’s phone is dead, etc lol.

Use Case 2: Patreon / Tipping experience

statement: As a fan, I want to tip a creator at a payment address that they’ve listed on one of their profiles.

This has become a major part of online life especially. The need for what is essentially a mailbox that people can send money to.

Many peoples’ jobs are in this internet industry now. Artists, Youtubers, Twitch streamers, etc. They often have things like linktree with links to their stuff too.

In order for them to make money, they need the ability to have an “offline” address for people to send money to. The Patreon reference is different, because that is recurring payments. The main point here is that people are very comfortable with the concept of “addresses” now.

Solution: Are both of these solved with something like a third-party, always-on wallet? Perhaps. But does that defeat the purpose of Grin technology? Also perhaps xD

I think the best short-term use cases for grin are:

  • p2p transactions on surface/deep web
  • donation listeners on social media sites
  • invoices for surface web stores (e.g. mine used to run knockturn allee by @hashmap )

Third party always-on wallets with payout requests seem perfectly fine in the short term and add on to grin’s ecosystem in a positive way.

@trab
Thank you, these are the kind of use case I think we should be collecting. Lets brainstorm a bit about these use cases.

Use Case 1: Venmo/Cash App experience
I also was thinking about the IOU kind of situations. As long as the creditor is online, this should not be a problem. Meaning that mobile phone wallets are key for these kind of use cases. Also I would love it, if you could for example let your buddies pay you their share of drinking money in Grin - not by owning it, but by them buying it for you.
The App CoinCollect offer(ed) such a feature.
Actually I think it is not an issue of interactivity if implemented correctly, as long as the magic happens under the hood, use does not need to know it is interactive. E.g. if we would develop a plugin for Telegram/Signal that allows you to send invoice request as slate-packs to your friends if their phone wallet is of-line. These slatepack messages are picked up by the wallet APP, this would very much feel like and work like CoinCollect, Venmo or Cash App. Added bonus, you do not need to be online when the transaction was send, as soon as your phone goes online (if it is not always online like most phones), it will pick up the transaction and proceed with handling them. Since these are your friends, they are in your contact lists, the wallet can simply auto-accept them.

Use Case 2: Patreon / Tipping experience
Indeed, the easiest solution, which would defeat partly the purpose of Grin, would be to use online/centralized wallets.
What I would prefer here is that we simply allow this pragmatic solution as well as more decentralized ones. Some possible solutions that would not defeat the purpose of Grin:

  • A good mobile wallet that is always online (IronBelly and Grin++ mobile) solves this issue.
  • Grin raspberry Pi’s, as council and especially @mcm-mike is working on plug and play Grin Raspberry Pi nodes. These are cheap, always online and could serve as always online wallets.
  • Many shops and charities that accept crypto already have a Bitcoin payment processor like Umbrel:
    https://getumbrel.com/
    What would be more simple than having Grin wallets that are loaded in their App store and can be readily loaded on these existing nodes/payment processors!

In any case thank you for these use cases, this is exactly how we need to think about Grin from a technologically agnostic perspective. We have to think in use cases first and then match the most simple solutions to them. There is a lot of space here to grow and improve the ecosystem, and I think it is safe to say that at least 80% of the use cases that people can think of can be solved without any consensus change such as implement non-interactive transactions, which we should not forget, have their issues of their own.

2 Likes

Wasn’t grinbox exactly that? If those solutions seem perfectly good, then why was that project abandoned and (seemingly) not supported by the community?

Even better, take one of the open source Matrix clients and add this functionality into it. Although, I have no idea what a slatepack is. If I understand correctly, a slatepack is literally a way to have offline transactions. If that is true, then grin already has offline transactions, right?

This is an oxymoron xD mobile apps are never “always online”. I’ve had horrible issues with Beam for this reason :slight_smile:

I do love the idea of a grin node being an installable app in things like Umbrel! Awesome idea :+1:

Yes, it surprised me that it was removed as option, maybe it was to much work. Maybe some community members found it to 'centralized. In a way exchange could facilitate this function now.

This exactly something that could be a project to be funded by the community council. Preferably plugins for matrix, signal, telegram - other suggestions welcome, as well as programmers willing to build these plugins :wink:

Basically a package in the form of a blob of text containing all transaction information. Hence it is handy since you can copy paste it or send it via email/signal/telegram/anything that supports text without worrying it gets meddled with or gets corrupted (some build in checksum).

Mobile phones should be always reachable, maybe something like push notifications are needed, but you are right it might be hard to build an APP that is low on battery yet always online. Even more reason we need support for other channels like Matrix, Signal, Telegram that can be used to route transactions.

Many potential projects guys, take your pick and apply for (community) funding

One problem I foresee is that there is no SDK for application integrations. The docs only show how to build or use existing wallets. There’s no documentation guide on how to programmatically create a slatepack, send it, unpack it, etc.

I think an SDK with methods for each step would be ideal.

Indeed, we need this. We need to build cross platform cross APP standards. Slatepacks help in that sense since that means you just need to load a blob of text/the slate-pack, it is the same for all wallet software. I have not delved to deeply in the API’s from grin-wallet (rust) and from Grin++, but I think both should have an API call to load a slate-pack in the wallet software.
So basically what is needed is a script or program that scans incomming text for labels like BEGINSLATEPACK.

ENDSLATEPACK, and simply makes an API call to the wallet with that blob of text.
Sounds easy enough, but I guess it is not trivial to get access to messages from for example Signal, since it wold provide a security risk to these Apps.

So you’d basically include the entire wallet in your application?

If there is an API, that would hint that there is a library version of the wallet that doesn’t include all the extra code that you don’t need, right?

I agree that slatepacks seem like an easy format. But how do we build and unpack them exactly? xD

That is the nice thing, you do not need to worry about it at all. What we need for development is just a program that scan incomming messages (from a Matrix server, website, email, telegram, Signal, anything that handles text) and then calls the API of an existing wallet.
So in programming terms what we need is a bridge or listener that links these messaging platforms to the wallet. The wallet does all the interpretation of incoming slate-packs - which is nothing more than a blob of text looks like:

BEGINSLATEPACK. some unreadable encrypted giberisch that contains the transaction info ENDSLATEPACK.

Oh simple!! So all Ironbelly needs is something like this Apple Developer Documentation

Each wallet should have a custom URI scheme that includes the slatepack. Then the messaging app doesn’t need to be aware of grin at all.

That would be one way. For example, open/scan URL/QR code on a website, to make donation. In it is some json that tells {slatepack address:grin…,if_not_online_default_to:some_action. E.g. if the tor address is not online, send to a certain matrix server. Preferably, your own wallet would also send with it some backup action in case your wallet is offline when you receive the response.

To be even more simple, just have a message like “to donate, please send a slatepack to this username on this app”. If we start using grin:// URIs then this would be even simpler for people to click and use.

That kind of flow with slatepacks is so much easier than even networks like monero.

Now how does someone generate an invoice to request a certain amount of money from someone?

Unfortunately such invoice transactions flows (RSR) with payment proofs, (needed to avoid settlement conflicts between the receiver and sender) are still in the RFC phase. Hopefully they will be implemented soon.

=> But on the plus side, grinnode life made this publicly available payment proof generator (still in beta phase)!

1 Like