user2107: Am I correct in thinking that this requires a DApp connector on the same device as the User's wallet?
Or could you have an app on the user's device that doesn't connect to their wallet, but somehow authorizes a transaction and sends that digital signature to your Dapp server which is running the PAB, which then submits the Tx?
My guess is it's the former, and the process would work like this:

dapp server sends the dapp client a message containing the
information required to make the Tx

dapp client has off chain code to construct the Tx, either simple Tx or smart contract Tx.

dapp client calls the dapp connector with the Tx, and the dapp connector requests permission from the user

when the user gives permission/enters their spending password, the Tx is submitted to the network by the dapp connector.


Does this sound correct?

user4627: That sounds correct. However, you're very flexible in who composes the transaction and who actually submits it to the network.
In general at some point a transaction needs to be signed by the end user's wallet (which holds the private key to your funds) - and this is the step that requires some sort of interface that is the DApp connector (possibly also to identify the user by the public address in the first place).
Regarding the client and server side of DApps, there is no single architecture that fits all use cases.
You can have a setup in which 1) the client passes its public address to the server, which then 2) generates a transaction, 3) passes it to the client for signing; 4) the client passes it (or even only the "signature" for this tx) back to the server for 5) final verification & server-side signing, before the server then 6) submits it to the network.
On the other hand a DApp strictly doesn't need a server at all, and everything could happen on the client side (eg in the browser through a lib like this https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser) - you can generate your transactions and submit them to the network through a wallet's dapp connector (eg using Nami wallet https://github.com/Berry-Pool/nami-wallet).
(A transaction is composed of a body, the witness set and optional metadata. The witness set holds the "signatures" of the different parties required to submit the transaction - thats how you can pass these parts around, compose them modularly, store them for later use / server side verifications etc. between clients and server)

2107: <p>Am I correct in thinking that this requires a DApp connector on the same device as the User's wallet?</p>
<p>Or could you have an app on the user's device that doesn't connect to their wallet, but somehow authorizes a transaction and sends that digital signature to your Dapp server which is running the PAB, which then submits the Tx?</p>
<p>My guess is it's the former, and the process would work like this:</p>
<ul>
<li><p>dapp server sends the dapp client a message containing the
information required to make the Tx</p>
</li>
<li><p>dapp client has off chain code to construct the Tx, either simple Tx or smart contract Tx.</p>
</li>
<li><p>dapp client calls the dapp connector with the Tx, and the dapp connector requests permission from the user</p>
</li>
<li><p>when the user gives permission/enters their spending password, the Tx is submitted to the network by the dapp connector.</p>
</li>
</ul>
<p>Does this sound correct?</p>
 4627: <p>That sounds correct. However, you're very flexible in who composes the transaction and who actually submits it to the network.</p>
<p>In general at some point a transaction needs to be signed by the end user's wallet <em>(which holds the private key to your funds)</em> - and this is the step that requires some sort of interface that is the DApp connector <em>(possibly also to identify the user by the public address in the first place)</em>.</p>
<p>Regarding the client and server side of DApps, there is no single architecture that fits all use cases.</p>
<p>You can have a setup in which 1) the client passes its public address to the server, which then 2) generates a transaction, 3) passes it to the client for signing; 4) the client passes it <em>(or even only the &quot;signature&quot; for this tx)</em> back to the server for 5) final verification &amp; server-side signing, before the server then 6) submits it to the network.</p>
<p>On the other hand a DApp strictly doesn't need a server at all, and everything could happen on the client side (eg in the browser through a lib like this <a href="https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser" rel="noreferrer">https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser</a>) - you can generate your transactions and submit them to the network through a wallet's dapp connector (eg using Nami wallet <a href="https://github.com/Berry-Pool/nami-wallet" rel="noreferrer">https://github.com/Berry-Pool/nami-wallet</a>).</p>
<p><em>(A transaction is composed of a body, the witness set and optional metadata. The witness set holds the &quot;signatures&quot; of the different parties required to submit the transaction - thats how you can pass these parts around, compose them modularly, store them for later use / server side verifications etc. between clients and server)</em></p>
