🕸️🐉 ↝ First set of posts cut off by header #8
Assignees
Labels
Comments
Gizmotronn
added
bug
Gizmotronn
added a commit
to Signal-K/graphql
that referenced
this issue
Jan 8, 2023
Gizmotronn
added a commit
that referenced
this issue
Jan 10, 2023
Gizmotronn
added a commit
that referenced
this issue
Jan 10, 2023
…mponent 🌝🧩 ↝ Fix CreatePost lib identifier, discovered addition to #8
Gizmotronn
added a commit
to Gizmotronn/comments
that referenced
this issue
Jan 17, 2023
…cloud Supabase instance Next step -> creating frontend component for users to update their profile information from (will merge with Signal-K/client@7d5dd61 contents later) Signal-K/sytizen#16 More styling issues in both `/test` and the root vite app - overlapping with Signal-K/client#12 Signal-K/client#9 Signal-K/client#8
Gizmotronn
added a commit
that referenced
this issue
Jan 28, 2023
Also fixed profile styling issue on my Lens profile (#7 #8 #9 #10 #11 #12): https://www.notion.so/skinetics/Threaded-Comments-2nd-iteration-flow-475d8a2328be4be8a1403256f094790e#61f363eddac74572b243ebb0c9c6513a Signal-K/sytizen#16
Gizmotronn
added a commit
that referenced
this issue
Feb 8, 2023
1. Completed authentication header for web client. To the end user it is 100% offchain, with user profiles being stored on a postgresql database. However, I've taken a dive into the Magic sdk to create wallet addresses for each user, as well as a Flask-based authentication handler for future metamask/wallet interaction. I've made this decision for a few reasons (like simplicity), but the main reason is for the client to seem like a regular journal platform and not be confusing, as well as follow the 'web3-agnostic' design language I favour for projects like this due to confusion and/or distrust of web3 products/teams. However, since each user will have a wallet address, they'll be able to interact with smart contracts and IPFS just fine. Further discussion will need to take place to discuss long-term suitability of this model, including things like gas fees (currently everything regarding transactions is occurring on Goerli [testnet] and gas fees will be processed by a "superuser" so that there's no restrictions or huge expenses) and how we go about getting users to trust the web3 nature (which I've got a lot of experience with). However, I don't fully know the exact demographics we'll be targeting & also I understand that that's quite a while away, so I'll raise it now but won't spend any time thinking about it until the time comes
2. I've continued with the contracts for proposals/publications & updating the metadata standards. I favour a lazy minting approach with data processing being handled by a Flask blueprint (which is a formula my team have developed on signal-k/sytizen). Right now I'm using Thirdweb & Moralis for the contract interactions and I have also, with much difficulty, succeeded in getting Moralis to self-host on my Postgres server. Finally, I've begun the process of optimising the base layer contracts so that the gas fees (which are already reduced post-merge) are essentially negligible at this time.
3. File upload for posts/articles feature on the web client is complete, and the smart contracts now receive all file upload metadata from this.
4. Begun a new flask blueprint (forked from point #2) to generate dataset previews based on which modules (e.g. lightkurve) are used and to add interactive nature to the 'sandbox' feature discussed earlier
5. Reluctantly continued some documentation
(above message from the Desci discord, see Signal-K/sytizen#16 for more info)
|
Lens is no longer relevant for now, so I think we can close this |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: