PeerMessage

[kactech]

I think that Peercoin needs another, unique type of client - full download, no relaying, no/limited verification client.

[kactech]

Imgur can store 10MB of encrypted data http://i.imgur.com/dfnevvg.png , more in multipart mode - I'll publish java library for reference.
Edit: http://imgur.com/delete/aeKXSJS9tb7zLb6 delete img link - let's not abuse their great service.

[jooize]

The final thing I'd say is just that PeerMessage is just one cog in a wheel of a much larger app.

Cool! Looking forward to it.

May I suggest Peermessage over PeerMessage? I might be the only nutcase caring about this, but it would also go in line with most other Peercoin projects. If you're inclined otherwise, go with it.

[mhps]

[quote="jooize, post:47, topic:3247"]

The final thing I'd say is just that PeerMessage is just one cog in a wheel of a much larger app.

Cool! Looking forward to it.

May I suggest Peermessage over PeerMessage? I might be the only nutcase caring about this, but it would also go in line with most other Peercoin projects. If you're inclined otherwise, go with it.[/quote]

Yes the same as with Bitcoin and Internet. Make it one word, as in "I Peermessaged her."

[crypto_coiner]

NuShareHolder Chatting Service
https://discuss.nubits.com/t/nushareholder-chatting-service/1355

"As a result, we would have a public message board that offers a functionality very similar to bitmessage with the exception that anyone can read the messages and that messages are stored in the block chain forever. "

[emeth]

Imgur can store 10MB of encrypted data http://i.imgur.com/dfnevvg.png , more in multipart mode - I'll publish java library for reference.
Edit: http://imgur.com/delete/aeKXSJS9tb7zLb6 delete img link - let's not abuse their great service.

After thinking about it for a while, I agree. I removed support for imgur - I like their service. Three external stores (tinyurl, is.gd, and pastebin) is sufficient redundancy imo.

Cool! Looking forward to it.

May I suggest Peermessage over PeerMessage? I might be the only nutcase caring about this, but it would also go in line with most other Peercoin projects. If you're inclined otherwise, go with it.

I'm open to that. My only concern is "peer"-fatigue. I just renamed the overall app to PeerApps, and the first two apps active on the platform are PeerMessage (encrypted email) and the new app I just release PeerBlog (non-encrypted microblogging).

NuShareHolder Chatting Service
https://discuss.nubits.com/t/nushareholder-chatting-service/1355

"As a result, we would have a public message board that offers a functionality very similar to bitmessage with the exception that anyone can read the messages and that messages are stored in the block chain forever. "

This is very cool, and shows a valid use-case for this kind of app. After Bitcoin 0.9 gets merged to Peercoin, then to the Nu*, they'd totally be able to fork it without much work - I'd love to get them involved in the platform.

Granted, there may be misgivings with the external cloud storage currently used, but once Sunny King is done with his auxiliary blockchain/sidechain model, that'll be resolved too.

[pillow]

Hm I was thinking, perhaps it would be possible to build a decentralized version of localbitcoins (but instead localpeercoins) ontop of / using peermessage. There needs to be some kind of channel where people could post info on, but since messaging is fixed that shouldn't be a showstopper. A simple open maps think to go along with that... Hmm..
a

[emeth]

Exactly, Pillow.

This PeerApps infrastructure will let anyone build an app on top of it. The two sample modules (PeerMessage and PeerBlog) can be cloned and serve as the base for any new modules. I expect people to come up with all sorts of interesting apps - for example, a namecoin / peerdns module, or a module that serves as an oauth-like login mechanism using signed/verified messages to "login" a user as a peercoin address. The larger app I've hinted I'm working on will also be another module.

The infrastructure is in place, but there's still a lot of work I want to do on it. I want to separate the databases for each module, segregate the static files, bundle it all in a wxPython taskbaricon for it's "always on" UI, and prepare the backend to be used in light wallets (scanning blocks on a blockchain explorer api). Lots to do, but plenty of time to do it in.

I, for one, am excited about the possibilities.

[masterOfDisaster]

I'm overwhelmed by the possibilities!
Using multisignature addresses one could create a kind of message board that shares information between several people, but not the whole world.
Even services like Facebook (or other social media stuff) without the data security drawbacks are thinkable.
Unlike at Facebook each user were in total control of the data and could really only share it with the ones he/she likes!

PeerMessage is revolutionary, because it offers a more convenient way of using cryptography to protect information than all other approaches I'm aware of.
While StorJ has an operational model that pays for offering file space, using free services while encrypting the stored data with PeerMessage is another implementation we will likely see.

The longer I think about PeerMessage the more I'm in awe.

[teek]

I, for one, am excited about the possibilities.

this project is a beast!

[pillow]

The more I think about Peerapps (used to be Peermessage, for everyone out there confused about the difference between Peerapps and Peermessage) the more stoked I am.

For instance, this one:
http://cointelegraph.com/news/113579/coinspark-open-sources-a-paypal-like-messaging-feature-for-coinspark

With messaging using Peerapps, this could be "easily added", right?

Another very interesting technology is Ricardian contracts (http://iang.org/papers/ricardian_contract.html) which basically put is human-and-machine-readable contracts. Open Transactions uses them and so does Open Bazaar.

Since a Ricardian contracts is a message, we could publish Ricardian contracts, send them to one-another and enter into binding agreements. If these contracts were published on #channels that people are listening to, we could even get trading going using them and it would be totally decentralized.

I don't remember whether or not Peercoin has "this time locked feature", but this feature could be used to create Ricardian contracts with expiration dates and so forth and so on.

Powerful stuff this Peerapp tech. :-*

[mhps]

Terrific work emeth.

Since it is written in python, can it act as a simplified local smtp daemon to allow local mailers such as thunderbird to send/receive/manage peermessage as if they were emails?

That's a crazy interesting idea. To my knowledge, there's no reason it couldn't do so.

Maybe you could just interface peermessage with bmwrapper or BitMailServer (for windows). It seems easy to use.

I have tried the BitMailServer and find it working well and not very difficult to set up. If peermessage implement the apis it can skip provinding the gui and use external mailers.

[AnnexOrbis]

What happened with this project?

[Sentinelrv]

What happened with this project?

Emeth has been waiting for Peercoin v0.5 to release, which should be happening soon. It contains functionality he needs to make this work.

[AnnexOrbis]

What happened with this project?

Emeth has been waiting for Peercoin v0.5 to release, which should be happening soon. It contains functionality he needs to make this work.

Thank you for the reply.

[AnnexOrbis]

Just curious if this project is going to the light. I haven't seen any updates.

Thanks.

[Sentinelrv]

Just curious if this project is going to the light. I haven't seen any updates.

Thanks.

Try emailing Emeth. His email is listed on his profile. Let us know what you find out. I believe he's waiting for the protocol to switch, but an update would be good.

[AnnexOrbis]

Earth to [member=32312]emeth[/member],

Do you have any updates for us?

Thank you.

[caribou]

https://github.com/sunnyking/ppcoin/commit/bb6a9f6c00b600ee2390bdf7bee6ca88ecda7f6f#diff-fa018f4d28b5116a35b36b72fc9f4e51R19

sunnyking added a note on Sep 18 2015
"The thinking is to clearly distinguish stake transaction from standard transaction. Since stake has value 0 with vout[0], standard tx would have value > 0 with vout[0], but can have zero value with other outputs.
I agree it might be a bit redundant though, since stake is defined as having empty vout[0], which means both 0 value and an empty script. Though I don't really see the need to support a data transaction where all outputs have 0 value?
In the current implementation, it requires that the OP_RETURN output to NOT be vout[0]."

emeth- added a note on Sep 18 2015
"Here's how my transactions look:
https://github.com/Peerapps/Peerapps/blob/master/blockchain_func.py#L117

Change goes to vout[0], with op_return after that - which means it should be fine with the above, right?

Note that in the current implementation, nodes are not propagating the transaction and I haven't been able to drill down to why yet.

I agree with mably on this though - we should try not to diverge from bitcoin core if at all possible."

[ceder]

OMG even Emeth is busy with pokemon :'(> https://github.com/emeth-/pokelocater