I want to create some NFT's which will be sound files.
Is the size in https://docs.solana.com/storage_rent_economics pay per byte scenario the size of the sound or size of the metadata related to the ledger ?
So is the token data stored in the ledger and this have the cost associated with it or is there only reference URL stored in the ledger and the size of rent is that URL reference plus internal data of Solana ?
I am trying work out if it is the size of the token like picture or sound then the bigger the data the bigger the rent costs.
The metadata onchain and off-chain in solana NFTs are standardised by the metaplex protocol. Docs are here: https://docs.metaplex.com/token-metadata/v1.1.0/api
The actual on-chain struct is what you would pay in rent for as seen here in the metaplex docs and can also be confirmed in their open source github:
https://docs.metaplex.com/token-metadata/v1.1.0/specification#metadata-struct
The on-chain URI it references would then point to your off-chain json metadata defined further down on the same page linked above. This off-chain json metadata also has a uri key which would probably be where you would finally point to your sound files. The json metadata and sound files should be uploaded to a "global, permanent hard drive" such as the arweave network.
So to answer your question briefly, you will pay minimal rent costs in SOL if you don't store your sound file on-chain.
Related
Health related data for a user is a privacy thing and its need to be very secure i.e. it needs to be stored in secure place. For example, while I was watching Apple's official video on Finger print unlock, they told that finger print data is stored at place where it is impossible to hack. So, for a curiosity, I have a question in mind that where these data are securely stored?
I have had a look at this link from Apple Documentation but could not found the information on it. One thing I have figured out is that data are encrypted and stored but where?
Does anyone has idea on the same?
Apple describes the security attributes of various iOS features in this document. To quote:
This data is stored in Data Protection class Protected Unless Open.
Access to the data is relinquished 10 minutes after device locks, and
data becomes accessible the next time user enters their passcode or
uses Touch ID or Face ID to unlock the device.
Read the "Encryption and Data Protection" section of the document to learn more about Data Protection. Any app can use the "Protected Unless Open" data protection class for its persistent data.
As you already know, NSUserDefaults is simple and effective for saving small, simple bits of data, like NSNumbers or NSStrings, to your device’s file system. But this data is in no way stored securely as hackers can access it pretty easily from the device.
You have figured out that sensitive data are encrypted. But you need to find the answer where it need to be stored. The Answer is:
Keychain Services:Apple has provided the Keychain Services API to deal with this problem and help developers build apps that safely handle passwords and other sensitive information.
Now the question might rase why?? and the answer is:
Keychain is great because data encryption automatically is taken care of before it is stored in the file system so there is no need to waste time building encryption algorithms.
You can go through this link for better explanation.
https://developer.apple.com/documentation/security/keychain_services
I am so happy that I get an ID per device, so I can keep data per user anonymously with firebase! The only thing that could be better is if I could get an id per user's iCloud storage for the app.
I understand that how the authentication token is maintained per app, at least on the web, is that it is stored in local storage. It implies that a similar approach is being used per app in iOS in something like UserDefaults. I'm hoping there's an easy way to keep it instead in NSUbiquitousKeyValueStore.
edit with use case:
I have an app that is (with permission) capturing and anonymously collecting location data. I would like to have that data stored per user rather than per device, and I essentially can't use signed logins.
(actually, the reality is that I am not capturing that in firestore, I am capturing accompanying metric data from other apps designed to work with this one)
So "why anonymous?", right? I am collecting time series data for third party apps - this presents risk of "use" to the user, and loss of control for that same data for the subscriber apps using the service I am writing.
Honestly, at a later point in time this might be converted to a library that allows apps to swarm their information together instead. But there are overhead concerns, and difficulty in trust for sharing data, with that approach and for my research project that approach is further from topic.
I couldn't find resources discussing the difference between the three download methods in the firebase storage documentation and pros/cons of each. I would like some clarification about the firebase storage documentation.
My App
Displays 100 images ranging from 10 KB-500 KB in size on a table view
Will be used in a location where internet connection and/or phone service could be very weak
Could be used by many users
3 methods for downloading from Firebase storage
Download to NSData in memory
This is the easiest way to quickly download a file, but it must load entire contents of your file into memory. If you request a file larger than your app's available memory, your app will crash. To protect against memory issues, make sure to set the max size to something you know your app can handle, or use another download method.
Question: I tried this method to display 100 images that were 10KB-500KB in size on my table view cells. Although my app didn't crash, as I scrolled through my table, my memory usage increased to 268 mb. Would this method not be recommended for displaying a lot of images?
Download to an NSURL representing a file on device
The writeToFile:completion: method downloads a file directly to a local device. Use this if your users want to have access to the file while offline or to share in a different app.
Question: Does that mean all images from firebase storage will be downloaded on user's phone? Does that mean that the app will be taking up a large percentage of the available storage on the phone?
Generate an NSURL representing the file online
If you already have download infrastructure based around URLs, or just want a URL to share, you can get the download URL for a file by calling the downloadURLWithCompletion: method on a storage reference.
Question: Does this method require a strong internet connection and/or phone service connection to work?
Generally, your memory usage should not be affected by the method of retrieval. As long as you're displaying the 100 images, their data will be stored in the memory and should have the same size if they're identically formatted/compressed.
Either way you go with, I suggest you implement pagination (for your convenience, this question's answer might serve as a good implementation reference/guide) to possibly decrease the memory and network usage.
Now, down to comparing the methods:
Method 1
...but it must load entire contents of your file into memory.
This line might throw some people off thinking it's a
memory-inefficient solution, when all it really means is that you
cannot retrieve parts of the data, you can only download the entire
file. In the case of storing images, you probably would want that for
the data to make sense.
If your application needs to download the images every time the users
access it (i.e if your images are regularly updated), then this
method will probably suit you best. The images will be downloaded
every time the application starts, then they'll get discarded when
you kill it.
You stated that a part of your user base might have a weak internet
connection and so the next method might be more efficient and
user-friendly
Method 2
First off, the answers to your questions:
Yes. The images downloaded using this method will be stored on the users' devices.
The images should take up about the same size they're taking on Firebase storage.
Secondly, if you plan to use this method, then I suggest you store a
timestamp (or any sort of marker) in your database for when the last
change to the images occurred. Then, every time the app opens up, do
the following flow:
If no images are downloaded -> download images and store the database timestamp locally
If the local timestamp does not equal the timestamp on the database -> download images and store the new timestamp locally
Else -> use the images you already have, they should be identical to the ones in Firebase storage
That would be the best way to go if your network usage priority is
higher than that of the local storage.
And finally...
Method 3 (not really)
This is not a data download method, this simply generates a
download URL given a reference to the child. You can then use that
URL to download the data in your app or elsewhere as long as the used
app or API is authorized to access your Firebase storage.
Update:
The URL is generated from a Firebase reference (FIRDatabase.database().reference().child("exampleReference")) and would look like this: (Note: this is a fake link that will not actually work, just used for illustration purpose)
https://firebasestorage.googleapis.com/v0/b/projectName.appspot.com/o/somePathHere%2FchildName%2FsomeOtherChildName%2FimageName.jpg?alt=media&token=1a8f83a7-95xf-4d3s-nf9b-99a274927bcb
If you simply try to access that link you generate through any regular web-browser (assuming you don't have any Firebase rule that conflicts with that in your project), you can directly download that image from anywhere, not just through your app.
So in conclusion, this "Method" does not download data from Firebase storage, it just returns a download URL for your data in case you want a direct link.
Is there a way to limit the signer attachment file size in docusign, either using the API or through settings at the DocuSign web site. I have read (in the API guide) that there is a 25 MB limit for attachments. Is there any way to restrict this to a smaller number?
Curiously, the document that triggered this issue was 31 MB in size. Our customer was able to upload a document that big, but our application experienced timeout issues because it took too long to download it. Why was the customer able to upload such a big attachment?
Thanks.
[1] No there is not currently a way that outside applications could limit the platform wide limit of ~25MB per envelope that DocuSign has in place. It is recommended that you add logic to your app/integration that checks the file size BEFORE you make the API call to create the envelope and stops the user from using that document if it's too large.
[2] The reason why a particular 30MB document was accepted by the platform but other 30MB documents might error out is due to encryption. Whenever you create a new DocuSign envelope the system automatically encrypts and hashes each document. This in turn bloats the envelope larger. The true limit of the platform is actually 50MB per envelope, so based on the actual data and bytes of your docs different ones will be enlarged to different sizes, and some will exceed that 50MB limit whereas others might not.
What are the guidelines to follow such that data can be previewed nicely on CKAN Data Preview tool? I am working on CKAN and have been uploading data or linking it to external websites. Some could be previewed nicely, some not. I have been researching online about machine-readability and could not find any resources pertaining to CKAN that states the correct way to structure data such that it can be previewed nicely on CKAN. I hope to gather responses from all of you on the do's and don'ts so that it will come in useful to CKAN publishers and developers in future.
For example, data has to be in a tabular format with labelled rows and columns. Data has to be stored on the first tab of the spreadsheet as the other tabs cannot be previewed. Spreadsheet cannot contain formulas or macros. Data has to be stored in the correct file format (refer to another topic of mine: Which file formats can be previewed on CKAN Data Preview tool?)
Thanks!
Since CKAN is an open source data management system, it does not have a specific guidelines on the machine readability of data. Instead, you might want to take a look at the current standard for data openness and machine readability right here: http://5stardata.info
UK's implementation of CKAN also includes a set of plugins which help to rate the openness of the data based on the 5 star open data scheme right here: https://github.com/ckan/ckanext-qa
Check Data Pusher Logs - When you host files in the CKAN Data Store - the tool that loads the data in provides logs - these will reveal problems with the format of data.
Store Data Locally - Where possible store the data locally - because data stored elsewhere has to go through the proxy process (https://github.com/okfn/dataproxy) which is slower and is of course subject to the external site maintaining availability.
Consider File Size and Connectivity - Keep the file size small enough for your installation and connectivity that it doesn't time out when loading into the CKAN Data Explorer. If the file is externally hosted and is large and the access to the file is slow ( poor connectivity or too much load) you will end up with timeouts since the proxy must read the entire file before it is presented for preview. Again hosting data locally should mean better control over the load on compute resource and ensure that the data explorer works consistently.
Use Open File Formats - If you are using CKAN to publish open data - then the community generally holds that is is best to publish data in open formats (e.g. CSV, TXT) rather than proprietary ones (eg. XLS). Beyond increasing access to data to all users - and reducing the chance that the data is not properly structured for preview - this has other advantages. For example, it is harder to accidentally publish information that you didn't mean to.
Validate Your Data -Use tools like CSVKIT to check that your data is in good shape.
The best way to get good previewing experiences is to start using the DataStore. When viewing remote data CKAN has to use the DataProxy to do its best to guess data types and convert the data to a form it can preview. If you put the data into the DataStore that isn't necessary as the data will already be in a good structure and types will have been set (e.g. you'll know this column is a date rather than a number).