Your gitignore contains :
/secrets.py
/secrets.new.py

Obviously, you don't wanna commit your secrets.py file... but the secrets.new.py should not be ignored, as we don't have any info on how to build a secrets.py file.

Watching the source,
I found some parameters to write down but don't know what's there value.

from secrets import BLOCKCHAIN_WALLET_GUID, BLOCKCHAIN_PASSWORD_1, BLOCKCHAIN_PASSWORD_2, CALLBACK_SECRET,
from secrets import ADMIN_EMAIL
from secrets import SECRET_ADMIN_PATH

example:

SECRET_ADMIN_PATH = admin.py
NameError: name 'admin' is not defined

I tried (different branches) to get at least the /api part working on my machine -- tried it via app engine sdk / virtualenv but got different errors...

Could you please also provide some information about the variables used in secrets.py?
A Blockchain.info API account is also required -- right?
Anything else to know?

Thanks!

Demonstrating data ownership without revealing actual data.
You can publicly reveal the digest and if conflict arises you can prove you had the data that generates the digest. Useful for copyrighted material, patents, etc.

Doesn't say how. I can see at least two ways:

1. Submitting signed or watermarked documents that can be used as proof to the ownership of both that and the unwatermarked version, by virtue of being dated earlier than yourself or anyone else submitting the unwatermarked version.
2. Submitting a snapshot of your public web page where you list the (submitted) hashes you own every time you update the page.

Neither method is really optimal (both require extra submissions) and neither is presented on the page.
Perhaps there should be one of the following:

1. A field for an email address or other public identifier to be hashed and appended (so that the existence of the unique document can be verified without inputting the author).
2. A field for an email address or other public identifier to salt the hash with (which doesn't create extra data, so will not require weaker hashes). This method is identical to manual solution 1 above.
3. Encrypting the file with the author's private key to verify that not only did they possess the file at the date, but were in fact the person responsible for registering it. (So that a third party can not use the feature for defamation.)

On the page for verifying a document, it says "Select a document and have it certified in the Bitcoin blockchain". It would be better to have a separate page saying something like: "Select a document for verification of existence".

Suggested by Titus and many others

I'm thinking of incorporating the proof of ownership feature, in a decentralized way. This is by having the user send a special transaction with a bitcoin address of his own, so that he can later prove he owns it by signing a message.

An idea of how to make this work (not sure if possible): use a p2sh op_return output, and have the user send a tx there.

Seems the domain name expired: http://proofofexistence.com/ ?

I've been looking at the code but didn't understand why you need to stablish a minimum amount of satoshis, or why that minimum is so high. It's 5mBTC instead of the 0.1mBTC that are really needed for paying the transaction fees. I could understand it if you say that you are charging a fee for the service, but on the payment page you say "You'll need to pay 5 mBTC to do so, required by our embedding algorithm, and you are also invited to tip us with whatever value you find appropiate."

It feels like a scam to me, I don't see a REAL requirement for that amount, instead I see a hardcoded value. Could you please explain this?

Because some people speculate that OP_RETURN might not persist in the Bitcoin Blockchain, I was wondering about a dedicated sidechain that would authenticate digital objects.

Of course I'm referring to the emergence of interest in the Sidechain concept as brought forth by Blockstream raising lots of $$$.

Any interest for POE considering this?

When I'm on the page confirming existence of the document, I see the
  following information:

    Document information d2d59c63a30049c1c75930db61d398959dc5e32ca27772d9b970f261715c7784
    Registered in our servers since: 2014-06-26 09:42:00
    Transaction broadcast timestamp: 2014-06-26 10:46:42

    Document proof embedded in the Bitcoin blockchain!

  I think this is really hard to digest for non-technical users who may
  not even know what a blockchain is.  It would be better to first say
  something like this (on a large font).

    This document was registered on 2014-06-26 at 09:42:00.

  Then you could list technical details in a smaller font for those
  users who know how to interpret it.

Suggested by Titus

It looks totally blank

Great work on POE! I have some problems with call back and secret.py. I would be much appreciated if you can help me : )

1)PAYMENT_ADDRESS and PAYMENT_PRIVATE_KEY.
Is the payment address the default one in my blockchain.info wallet?and is PAYMENT_PRIVATE_KEY the related one with payment address exported from blockchain.info wallet.
I have noticed that it would be decoded by base58 in encoding.py, so I managed to generate a base58 format private with bitaddress.org, which starts with 5 and has 51characters.

2)And I have also noticed that SECRET_ADMIN_PATH is part of some URL in admin.py. But I'm not so sure about "/autopay ".Would it automatically pay something?
I have noticed that all OP_RETURNs are embedded within a tx which goes from 0.0001 to an unparsed address.

3)About the callback url.
And because in secret.py, there is no other URL set entries, so is SECRET_ADMIN_PATH part of the callback URL?
Or is the callback url created in another way?

4)How to set CALLBACK_SECRET SECRET_ADMIN_PATH and the related http notification callbackURL input aera in blockchain.info right.

5)is everything working in this way:
a)file hash generated in local browser,doctype added as marker bytes, hex it and add OP_RETRUN
before it. And this becomes a script.
b)use wif privatekey to generate an address to receive 5mbtc as well as 0.0001btc OP_RETURN tx.
(Here I have a question: is there only one tx or two to embed the OP_RETURN metadata?)
C)create a tx (from PAYMENT_ADDRESS to this wif generated address, 0.0001 btc?)with blockchain info api without broadcasting it.Depack it and embed OP_RETURN script into it, then repack it.
d)listening to the callback URL, if 5mbtc is received, then automatically broadcast this raw tx via "insight bitpay".(if so there are two txs)

Key problems:
1)how to set callback URL both in secrets.py and blockchain.info?
2)How to set secret admin path?
3)How to set ENCRYPTED WALLET's path on Ubuntu?(offline version)
4)how to set PAYMENT_ADDRESS and PAYMENT_PRIVATE_KEY?

thank you maraoz

Hello! Do you have email address?
How can I contact you?

Super excited about proofofexistence. I'm wondering if there is any way to add a param to the register API call to indicate the address where you'd like the hash to go?

It would be useful if the API responded to a status request with the transaction id.

Example:

Http request:

http://proofofexistence.com/api/v1/status?d=15db6dbff597875ea13246e1c166802b690663c4e0635bfca78049d5a8762832

Response:

{
    "status": "confirmed",
    "success": true,
    "transaction": "9dcb4b3a6ffa2106dc552f4699ad15073d1a7cca5413ebd4fae0c736bbe1946c"
}