Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last month.
Improve this question
i have completed my Solidity contract, which I want to use to upload a PDF/JPG file onto the Ethereum Blockchain. I just calculated the cost at around .70 USD per hour (#720 hours per month, the cost is an astonishing USD 504). Can you help with these questions please?
What is the most cost-effective way to store a 1MB file on the Blockchain
Would you recommend IPFS? Is it really free?
Is there additional cost every time I check if the file is authentic? Based on user-uploaded hash and comparing with the uploaded hash or file
Can you please help in suggesting a solution where the cost of storing and checking is kept to a minimum?
Sorry, too many questions. But any help is super appreciated. 🙏 Thanks
I have checked on the Web to see the costs. It varies from USD 0.3 to USD 0.8 per hour. I only want to upload a small file on the blockchain and later check if tha file is authentic by comparing to the user-provided file.
What is the most cost-effective way to store a 1MB file on the Blockchain
Use a chain specialised to storage like Arweave, Filecoin or Storj. Ethereum is designed for financial applications, not for storing files. You should not use Ethereum for something it is not designed for.
Would you recommend IPFS? Is it really free?
IPFS is not persistent storage but a cache layer. Think it as a BitTorrent alternative. You still need to pay to host somewhere.
Is there additional cost every time I check if the file is authentic? Based on user-uploaded hash and comparing with the uploaded hash or file
For all blockchain systems I know at the moment, reads are free.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I have an idea for an application where I would like the following to happen:
A group of people / their devices create a sharing session -->
They can set a time frame for this session (could be one hour or one day, but not long term). -->
Once the session is created they will go through their day capturing the data which I want to be shared automatically between all the devices. -->
At the end of the session each device will be able to choose what of the data collected they would like to keep locally on their device despite who may have collected it. -->
Once each of the devices have saved what they would like, the shared storage would be removed.
What I am struggling on is the best technology for sharing the data. I would rather not have notifications each time data is shared.
I have looked at Multipeer Connectivity as a solution, where each bit of data would get sent to each device and stored locally, but the biggest drawback is the inability to maintain a session in the background, which is likely where the application would reside for the majority of the time period.
Any direction or areas to research would be greatly appreciated. Note: at least to start with I would be looking to implement this in IOS
I would imagine a temporary folder on a web server (kinda like shared cloud folders) would be among the better solutions to this.
Doesn't require physical proximity to other participant. Could be in entirely different countries and it wouldn't matter. There's however nothing stopping you from setting such a limitation anyway.
Would be far easier to implement tech-wise. Especially considering cross-platform support.
You espace many logitical problems, such as storage space on individual devies. Like What happens when participant wants to keep some data, but there's not even enough space to even see a preview of what the participant is missing out on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I understand Keychain is designed for saving Passwords, InternetPasswords, cryptographic keys, etc. However, why not just save small encodable models as well?
For example, an encodable and decodable structure that holds about 100 properties of user sensitive preferences.
I tried this and it worked pretty well. Although, there is not much concrete information available and I want to understand if there are any downsides to doing this.
Nothing actually prevents you from doing it, as the encoded data model will be in the form of Data/NSData. There may be a pair of points to keep in mind before going in that direction:
there’s an actual size limit per
single keychain item ( which I personally could not find officially stated, but I remember that writing a keychain item which data size was greater than about 2 MB, led to a keychain write error ). That means you should be careful on how big the data model is ( for example using short CodingKeys instead of the actual property names, would use less bytes in the resulting data block to be written )
keychain data does not get deleted when the user deletes the app. Whether this will stay like this forever or not I can’t tell, but is a fact as per now, and this means you may need to put a logic in your app to make sure that another installation on top of the previous one may not use the old/dirty data as unnecessary
I don’t discourage you from using the keychain for that, but in case, there are alternative approaches, like storing an encryption key on the keychain and using it to encrypt/decrypt your actual data models and write them securely in your app document folder. You can combine this with extra steps like NSFileProtectionComplete setting, make the encryption key in the keychain accessible only if the device is actually protected by passcode, and maybe, if you plan to store quite a lot of data, combine encryption and CoreData together.
Hope it helps
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I wish to track a set of data my educational app generates based on user challenges. Every nth challenge I want the app to send these metrics to my server so I can observe various things about the app.
Further, and most important, I need to uniquely identify each instance of my app so that I can watch the trends of a single user. I wish to persist this number through the life of the user's interaction with my program in an anonymous kind of way, and persist over multiple removal / installations on the same device.
Bonus points for what your opinion of the standard method of reporting these metrics to a web server are. XML? JSON? Simple NSURL's?
Bonus points for links to relevant Apple Documentation.
DISCLAIMER: (due to past experiences...)
I am relatively new to stack overflow. If this post doesn't conform to the standards of this site, please explain why before voting me off of the island.
You can't tie a device to a user unless you set up a username password combination. Nothing else will work if you expect to handle app removal, installation, or device upgrades.
As for preferred data-type. My preference is JSON. But that's just a preference and you'll get lots of other differing replies. Hence it's a sort of pointless question.
Take a look at this link. It explains what identifiers are constant when and in what situations they are not. He talks about the identifierforvendor and advertisingidentifier that are now the only supported unique identifiers you can access. They took away the UUID tracking as well as the MAC address method. You can still get the device serial number, but that method uses code that will get your app rejected by apple's app store review process.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a piece of software that creates a contract and captures the client's signature via gif and applies it to the contract (and spits out a pdf). Now, we're storing the data from the contract but when it comes to the signature, I'm not sure if I should.
Store it:
Pros: If the pdf document is lost, I can reconstruct the document instantly and easily for whomever needs it (us or client). (checked with the lawyers, reconstructing the document from data is legal and applicable as long as no data is or has changed)
Cons: Although I will never do anything with the stored signature, I can't be certain that, if I ever leave the company, my coworkers or replacements will honor that.
Don't Store it:
Pros: Ethical high ground, there's no option for anyone now or in the future to use that image and do anything with it. It keeps everyone honest.
Cons: Now there is no way to reconstruct the original document if the pdf is lost - which is a good possibility.
Talk to a lawyer.
If it's grey enough an area, I'd vote for don't-store-it.
Lawyers are the most important people to talk to in this case.
But I'd still say don't store it.
If necessary, I'd suggest storing the contract in a format from which you CANNOT extract the original GIF. Such as taking a png file for the whole document, or some other solution.
However, if you are storing the whole document with the signature embedded (and not extractable) then you have your ability to resend the signature, and you have no reason to store the unattached GIFs.
Ultimately, having the unattached GIFs is just providing an enormous opening to getting sued.
Storing them that way also opens you up to problems relating to 'pasting the wrong GIF' into a contract.
I would say that having the gif files in a way that does not EXPLICITLY bind them to the ONE contract they apply to is VERY dangerous.
EDIT
After reading your post again I would say that there isn't a point in storing the GIFs or the PDFs. You should have a hard copy somewhere of the signed document (and if you are losing hard copies of contracts, then there are SERIOUS organizational issues) and after that, you don't need the signed version anymore, you just need to know the terms of the contract. So as long as you can reconstruct the terms for reading over, then I don't see why you'd need the literal signature again. If you need to prove they signed it, go back to the hard copy.
Do you need to keep the signature for anything else? If not I'd store it only for as long as is required to produce the PDF, as there is no reason to keep it around.
In New Zealand the collection of personal data is governed by the Privacy Act and as such one of its requirements is the data is only stored for the length of time required for the reason the data was collected.
The signature can still be extracted from the PDF. So whether you store the original GIF does not seem to make a difference, security wise.
How about this for thought:
If it was an electronic signature, you would probably not be able/allowed to store it at all. You could store the signature+document (i.e. the crypto-signed hash of the initial document) and verify it with the public key, but to store a lot of client's private keys to be able to re-sign documents.
Imagine some one breaking in to the database and stealing those private keys (gifs or RSA/DSA keys). That store would be very useful/profitable to a criminal organization.
Do you want to expose yourself to that?
I don't know, a GIF can be re-created by anybody with a copy of the document and a scanner...not storing you lose the benefit of having it, without any real security value being added....
I would get legal advice on some text to place near the signature in the final document. Maybe something like:
John Hancock http://rightzinger.com/LibraryofProgress/FoundingFathers/John_Hancock_signature.gif
(electronically added signature)