IPFS on Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

IPFS on Smalltalk

Joe Shirk
Dear all, especially @Masashi

I wanted to draw attention to the http://ipfs.io project, "the permanent web" which works. It is a distributed peer-to-peer filesystem that works somewhat like bittorrent. You get the functionality of Git as well. It is truly ingenious. 

Since I have taken an interest in Smalltalk (I'm still learning) I have salivated at the  possibilities for, say Amber + ipfs. 

There is currently a call for APIs implemented in other languages;
I see no one there is interested in Smalltalk so I though I should undertake it, but it will be many months before I have the knowledge and there is no guarantee that I am up to the task... Now seeing that Masashi is working with filesystems, perhaps you would take an interest in this idea. 

The inventor Juan Benet has many brilliant ideas and has done several presentations to be found on the ipfs site. Unfortunately, he seems to drink a lot of coffee and talks extremely fast and does not enunciate, making the presentations very difficult to understand for those of whom english is a second language. I can definitely help with this by making a transcript if there is interest.


On Sat, Aug 22, 2015 at 1:00 PM, <[hidden email]> wrote:
Send Cuis mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cuis digest..."


Today's Topics:

   1. Re: Wrapper for file access in different Smalltalk dialects
      (Masashi UMEZAWA)
   2. New Cog VMs available... (Eliot Miranda)


----------------------------------------------------------------------

Message: 1
Date: Sat, 22 Aug 2015 22:15:43 +0900
From: Masashi UMEZAWA <[hidden email]>
To: Juan Vuletich <[hidden email]>
Cc: Discussion of Cuis Smalltalk <[hidden email]>,  "H. Hirzel"
        <[hidden email]>
Subject: Re: [Cuis] Wrapper for file access in different Smalltalk
        dialects
Message-ID:
        <CA+=[hidden email]>
Content-Type: text/plain; charset=UTF-8

Hi Juan,

Yes, I'm concerning about backward-compatibility.
FmFileEntry>>#readStream has been used long. So I would prefer just
adding new APIs.

Best regards,

> I guess I would prefer #readStream for the basic, raising exceptions api,
> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
> eating api" . In any case it is your call, I understand there is back
> compatibility to care about, and I'll be happy with your choice.
>
> Cheers,
> Juan Vuletich
>
>
>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<[hidden email]>:
>>>
>>> Hi Masashi,
>>>
>>> Recently we found that in FileMan, if we do
>>>
>>> 'inexistentFile' asFileEntry readStream
>>>
>>> we get an empty readStream.
>>>
>>> I think it is better to throw the #fileDoesNotExistException , as
>>> FileDirectory did, and let the user handle the exception appropriately.
>>> But
>>> I would not want to break compatibility with FileMan, as the main purpose
>>> of
>>> FileMan is to give compatibility amongst dialects.
>>>
>>> Are there good reasons to avoid the exception? Should we add another
>>> method,
>>> besides #readStream when we want a readStream strictly on existing file
>>> contents?
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>>
>>>
>>> On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
>>>>
>>>> Hello Juan,
>>>>
>>>> Thank you for the patches and more tests! I'll adapt those updates for
>>>> other FileMan ports.
>>>>
>>>> Best regards,
>>>>
>>>> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<[hidden email]>:
>>>>>
>>>>> Hi Masashi,
>>>>>
>>>>> I was trying FileMan tests today and I saw they create some folders in
>>>>> my
>>>>> drive. The names looked a bit strange, so I took a closer look and
>>>>> found
>>>>> a
>>>>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>>>>> creating
>>>>>         subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>>>>> it created
>>>>>          subDir/bbb/ccc/eee/ggg/test!
>>>>>
>>>>> So I wrote a few more tests on the issues I saw, and teaked the code to
>>>>> make
>>>>> them pass. The result is attached, and I think is useful for all ports
>>>>> of
>>>>> FileMan.
>>>>>
>>>>> Thanks,
>>>>> Juan Vuletich
>>>>>
>>>>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I think it is nice if FileMan is on the core package repository.
>>>>>>
>>>>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>>>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>>>>> methods of them.
>>>>>>
>>>>>> So we can gradually adopt FileMan interfaces and trim the
>>>>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>>>>
>>>>>> Another way of cleaning-up the file-related classes is to port
>>>>>> FileSystems to Cuis.
>>>>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>>>>> be an overkill.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<[hidden email]>:
>>>>>>>
>>>>>>> Hi Folks,
>>>>>>>
>>>>>>> I apologize for talking before taking even a quick look, but anyway,
>>>>>>> We'd
>>>>>>> take a good look at this. And seriously consider replacing files
>>>>>>> stuff
>>>>>>> in
>>>>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Masashi-san: opinions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Juan Vuletich
>>>>>>>
>>>>>>>
>>>>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>>>>>
>>>>>>>> Below are the comments from the FileMan package.
>>>>>>>>
>>>>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>>>>> package in Pharo?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>>>>> I represent a single file entry (including directory).
>>>>>>>> You can write data by #fileContents: , and read the data by
>>>>>>>> #fileContents.
>>>>>>>> ---
>>>>>>>> mu 11/6/2006 20:21!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>>>>> I represent a single file directory.
>>>>>>>> I implement various directory specific behaviors.
>>>>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>>>>> ---
>>>>>>>> mu 11/6/2006 20:21
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>>>>> I am an accessor to the low level file IO.
>>>>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>>>>> dialects.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>>>>> This is a simple example for adding special behaviors to
>>>>>>>> FmDirectoryEntry.
>>>>>>>> I backup file contents automatically, while users are not conscious
>>>>>>>> about
>>>>>>>> that.
>>>>>>>> Usage:
>>>>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>>>>> dir at: 'text' put: 'abc'.
>>>>>>>> dir at: 'text' put: 'def'.
>>>>>>>> (dir at: 'text') inspect. "def"
>>>>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>>>>> This is a simple example for adding special behaviors to
>>>>>>>> FmDirectoryEntry.
>>>>>>>> I put and get file contents as gzipped, while users are not
>>>>>>>> conscious
>>>>>>>> about that.
>>>>>>>> Usage:
>>>>>>>> | dir |
>>>>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>>>>> (dir binaryAt: 'bin') inspect.
>>>>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>>>>> (dir at: 'text') inspect.
>>>>>>>> I would be useful for storing/loading big contents in a simple
>>>>>>>> dictionary-like manner.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/17/15, H. Hirzel<[hidden email]>     wrote:
>>>>>>>>>
>>>>>>>>> Hello Masashi-san
>>>>>>>>>
>>>>>>>>> I'd like to come back to your FileMan package
>>>>>>>>>
>>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>
>>>>>>>>> and ask a question.
>>>>>>>>>
>>>>>>>>> Is this package a port from somewhere or did you write it from
>>>>>>>>> scratch?
>>>>>>>>>
>>>>>>>>> Some background information is appreciated.
>>>>>>>>>
>>>>>>>>> There is no description
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>>>>
>>>>>>>>> Thank you in advance
>>>>>>>>>
>>>>>>>>> Hannes Hirzel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/2/14, Masashi UMEZAWA<[hidden email]>     wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Thank you for the kind words. I've just started Cuis on March, and
>>>>>>>>>> I
>>>>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers
>>>>>>>>>> meeting.
>>>>>>>>>> It
>>>>>>>>>> was successful.
>>>>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and
>>>>>>>>>> SIXX
>>>>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>>>>> aboard!!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>>>>
>>>>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>>>>
>>>>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>     502"
>>>>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>>>>          'bounds owner submorphs fullBounds color extension'
>>>>>>>>>>>>          versus
>>>>>>>>>>>>         'owner submorphs location layoutNeeded layoutSpec
>>>>>>>>>>>> properties'
>>>>>>>>>>>> - layoutSpec
>>>>>>>>>>>> - PackageInfo
>>>>>>>>>>>> - version control with git
>>>>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>>>>> - your Unicode package
>>>>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>>>>> -
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>>>>                  https://github.com/search?q=cuis-smalltalk
>>>>>>>>>>>>
>>>>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>>>>
>>>>>>>>>>>> --Hannes
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/1/14, Ken Dickey<[hidden email]>     wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>>>>> "H. Hirzel"<[hidden email]>     wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>>>>
>>>>>>>>>>>>> He should introduce himself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>>>>> Tokyo:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>>>>
>>>>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>>>>> tweaks
>>>>>>>>>>>>> have
>>>>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>>>>> people
>>>>>>>>>>>>> there
>>>>>>>>>>>>> think about Cuis?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -KenD
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Cuis mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>>>
>>>>>>>
>>>>
>



--
[:masashi | ^umezawa]



------------------------------

Message: 2
Date: Sat, 22 Aug 2015 09:38:30 -0700
From: Eliot Miranda <[hidden email]>
To: Squeak Virtual Machine Development Discussion
        <[hidden email]>
Cc: The general-purpose Squeak developers list
        <[hidden email]>,        Discusses Development of
        Pharo <[hidden email]>,
        "[hidden email]"
        <[hidden email]>,    Discussion of Cuis Smalltalk
        <[hidden email]>
Subject: [Cuis] New Cog VMs available...
Message-ID:
        <CAC20JE1-f=nHr-jkoMsmpYaH=[hidden email]>
Content-Type: text/plain; charset="utf-8"

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.

Squeak V5 users will want to upgrade their VMs because they, along with
Smalltalk changes to follow soon, fix image segments.  But upgrading is not
a trivial process because the VMs on my site are not complete.  The best
way to update is to take a copy of the Squeak 5.0 all-in-one and replace
the main VM executable there-in with one from my site.  This gets you
up-to-date plugins and an up-to-date VM.  I hope that this process will get
easier soon.


------------------------------------------------------------------------
CogVM binaries as per VMMaker.oscog-eem.1441/r3427

Modify Spur ImageSegment load to become the segmentWordArray into an Array
of
the loaded objects if load is successful, hence decoupling ImageSegment from
the assumption that objects are allocated in order.

Fix Integer receiver, float arg comparison with NaNs in the machine-code
primitive.  This has started failing in the FloatTest>>testNaNCompare since
the
new machine-code perform primitive invoked the machine-code version of the
primitive.  The Interpretewr code has always been correct and the old
perform
primitive would always run the Interpreter primitive if it exsted, since
this
would probably be faster.

Fix the bug introduced by the fix to primitive function invocation in
VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
primitiveFunctionPointer appropriately when a jitted external primitive was
rebound, but it didn't remember to void the jit's record of the offset of
the
assignment that sets the primitiveFunctionPointer when switching between
profiling andf non-profiling regimes, so that the address from the wrong
regime
would remain and be used to smash prmitive code.  The fix is simply to void
the
externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
symptom is a hard VM crash when using AndreasSystemProfilier.

Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.

Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.

Newspeak:
Fix MNU for cogged self and outer sends.

Make the Newspeak VM packager include the V50 sources file instead of V41.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


------------------------------

End of Cuis Digest, Vol 38, Issue 21
************************************



--

Gmail is unsecure. Why? See: EFF Surveillance Self-Defense Project

My preferred secure email address: infomaniac(at)i2pmail(dot)org
(For more information, please see: About I2P)

If you prefer to send to this gmail account, consider using https://www.mailpile.is
 
My Public key: 

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: IPFS on Smalltalk

Juan Vuletich-4
Hi Joe,

Someone saying "awesome!" and "cool!" so many times at his own stuff
makes me a little uncomfortable... But, anyway:

It looks like Dropbox, but peer to peer, right?

The possibility of publishing and sharing stuff without a central
provider is of course desirable.

Before starting to implement bindings and calls to the api... Is that
really needed? It is integrated in the file system, so maybe not.

More interesting than that, what are some apps that could benefit from
it? How would they do that?

Cheers,
Juan Vuletich

On 8/24/2015 8:42 AM, Joe Shirk wrote:

> Dear all, especially @Masashi
>
> I wanted to draw attention to the http://ipfs.io project, "the
> permanent web" which works. It is a distributed peer-to-peer
> filesystem that works somewhat like bittorrent. You get the
> functionality of Git as well. It is truly ingenious.
>
> Since I have taken an interest in Smalltalk (I'm still learning) I
> have salivated at the  possibilities for, say Amber + ipfs.
>
> There is currently a call for APIs implemented in other languages;
> https://github.com/ipfs/ipfs/issues
> I see no one there is interested in Smalltalk so I though I should
> undertake it, but it will be many months before I have the knowledge
> and there is no guarantee that I am up to the task... Now seeing that
> Masashi is working with filesystems, perhaps you would take an
> interest in this idea.
>
> The inventor Juan Benet has many brilliant ideas and has done several
> presentations to be found on the ipfs site. Unfortunately, he seems to
> drink a lot of coffee and talks extremely fast and does not enunciate,
> making the presentations very difficult to understand for those of
> whom english is a second language. I can definitely help with this by
> making a transcript if there is interest.
>


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: IPFS on Smalltalk

Joe Shirk


Hi Juan,

I was trying to diplomatically imply that Benet's forte is not presentation, however the docs on the site and on github are adequate introductions, and I think it won't take long to see the value in what is  meant by "permanent" web that is content addressed instead of ip addressed.

I spoke too soon today, not aware that he had recently responded to my post a week ago:

https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050

As at the moment I am thumbing my smartphone, I have to be brief, but I'll try to cover the basics.

ipfs is a protocal that has the potential to eventually replace http altogether, though currently content on the ipfs network is accessible directly through the protocol as well as through http gateways.

ipfs is a content routing system, and so functions like a cdn, but it is distributed, so is like bittorrent. it does sync like dropbox, but the routing system ensures that copies of content migrate closer to demand, which could be an auditorium of people on a local wifi without external access. Real-time syncing to many peers is thus possible without latency.

There are working demos of HD videos streaming without latency from the network.

The Directed Acyclical Graph / Merkel Tree allows for just about any data structure, but is especially well designed for versioning. Everything is addressed by its hash fingerprint, so one can be absolutely sure what version one requests, but can also traverse the version tree if the content referenced is say, a software library that is a dependency for a certain package. Automatic forwarding to a more recent version is also a feature.

There is a name system too, that allows one to register a permanent or temporary namespace that references a version tree of any object.

All objects are stored in encrypted chunks, so privacy and publicity are controlled.

To me, this system implemented in smalltalk, and I suppose that should be squeak and amber, will make it possible to build distributed apps, because the app itself can be an object, not only its content or data. Implementing in smalltalk should mean that the complexity involved would be more easily managed with few bugs, compared to say, javascript or node.

I see ipfs as a route to put smalltalk in the limelight and on the cutting edge.

HTH

Joe



> Message: 5
> Date: Mon, 24 Aug 2015 10:48:43 -0300
> From: Juan Vuletich <[hidden email]>
> To: Discussion of Cuis Smalltalk <[hidden email]>
> Cc: Joe Shirk <[hidden email]>
> Subject: Re: [Cuis] IPFS on Smalltalk
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Joe,
>
> Someone saying "awesome!" and "cool!" so many times at his own stuff
> makes me a little uncomfortable... But, anyway:
>
> It looks like Dropbox, but peer to peer, right?
>
> The possibility of publishing and sharing stuff without a central
> provider is of course desirable.
>
> Before starting to implement bindings and calls to the api... Is that
> really needed? It is integrated in the file system, so maybe not.
>
> More interesting than that, what are some apps that could benefit from
> it? How would they do that?
>
> Cheers,
> Juan Vuletich
>
> On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > Dear all, especially @Masashi
> >
> > I wanted to draw attention to the http://ipfs.io project, "the
> > permanent web" which works. It is a distributed peer-to-peer
> > filesystem that works somewhat like bittorrent. You get the
> > functionality of Git as well. It is truly ingenious.
> >
> > Since I have taken an interest in Smalltalk (I'm still learning) I
> > have salivated at the  possibilities for, say Amber + ipfs.
> >
> > There is currently a call for APIs implemented in other languages;
> > https://github.com/ipfs/ipfs/issues
> > I see no one there is interested in Smalltalk so I though I should
> > undertake it, but it will be many months before I have the knowledge
> > and there is no guarantee that I am up to the task... Now seeing that
> > Masashi is working with filesystems, perhaps you would take an
> > interest in this idea.
> >
> > The inventor Juan Benet has many brilliant ideas and has done several
> > presentations to be found on the ipfs site. Unfortunately, he seems to
> > drink a lot of coffee and talks extremely fast and does not enunciate,
> > making the presentations very difficult to understand for those of
> > whom english is a second language. I can definitely help with this by
> > making a transcript if there is interest.
> >
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
>[hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 23
> ************************************


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: IPFS on Smalltalk

Joe Shirk
I don't know why I wrote 'Squeak' -- too much reading, I guess. I meant Pharo. My thinking was to make it work there first, then port to cuis and newspeak if there is a benefit in doing that. Perhaps that's not the best way to go about it. Any thoughts on this?

On Mon, Aug 24, 2015 at 10:25 AM, Joe Shirk <[hidden email]> wrote:

To me, this system implemented in smalltalk, and I suppose that should be squeak and amber, will make it possible to build distributed apps, because the app itself can be an object, not only its content or data. Implementing in smalltalk should mean that the complexity involved would be more easily managed with few bugs, compared to say, javascript or node.



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: IPFS on Smalltalk

Juan Vuletich-4
In reply to this post by Joe Shirk
Hi Joe,

On 8/24/2015 11:25 AM, Joe Shirk wrote:


Hi Juan,

I was trying to diplomatically imply that Benet's forte is not presentation, however the docs on the site and on github are adequate introductions, and I think it won't take long to see the value in what is  meant by "permanent" web that is content addressed instead of ip addressed.

I spoke too soon today, not aware that he had recently responded to my post a week ago:

https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050

As at the moment I am thumbing my smartphone, I have to be brief, but I'll try to cover the basics.

ipfs is a protocal that has the potential to eventually replace http altogether, though currently content on the ipfs network is accessible directly through the protocol as well as through http gateways.

ipfs is a content routing system, and so functions like a cdn, but it is distributed, so is like bittorrent. it does sync like dropbox, but the routing system ensures that copies of content migrate closer to demand, which could be an auditorium of people on a local wifi without external access. Real-time syncing to many peers is thus possible without latency.

There are working demos of HD videos streaming without latency from the network.

The Directed Acyclical Graph / Merkel Tree allows for just about any data structure, but is especially well designed for versioning. Everything is addressed by its hash fingerprint, so one can be absolutely sure what version one requests, but can also traverse the version tree if the content referenced is say, a software library that is a dependency for a certain package. Automatic forwarding to a more recent version is also a feature.

There is a name system too, that allows one to register a permanent or temporary namespace that references a version tree of any object.

All objects are stored in encrypted chunks, so privacy and publicity are controlled.

To me, this system implemented in smalltalk, and I suppose that should be squeak and amber, will make it possible to build distributed apps, because the app itself can be an object, not only its content or data. Implementing in smalltalk should mean that the complexity involved would be more easily managed with few bugs, compared to say, javascript or node.

I see ipfs as a route to put smalltalk in the limelight and on the cutting edge.

HTH

Joe


Thanks for the explanation. I think that implementing it, and playing and experimenting with it will show new and better ways of sharing code and content, in a word, objects.

I look forward for all this.

Cheers,
Juan Vuletich




> Message: 5
> Date: Mon, 24 Aug 2015 10:48:43 -0300
> From: Juan Vuletich <[hidden email]>
> To: Discussion of Cuis Smalltalk <[hidden email]>
> Cc: Joe Shirk <[hidden email]>
> Subject: Re: [Cuis] IPFS on Smalltalk
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Joe,
>
> Someone saying "awesome!" and "cool!" so many times at his own stuff
> makes me a little uncomfortable... But, anyway:
>
> It looks like Dropbox, but peer to peer, right?
>
> The possibility of publishing and sharing stuff without a central
> provider is of course desirable.
>
> Before starting to implement bindings and calls to the api... Is that
> really needed? It is integrated in the file system, so maybe not.
>
> More interesting than that, what are some apps that could benefit from
> it? How would they do that?
>
> Cheers,
> Juan Vuletich
>
> On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > Dear all, especially @Masashi
> >
> > I wanted to draw attention to the http://ipfs.io project, "the
> > permanent web" which works. It is a distributed peer-to-peer
> > filesystem that works somewhat like bittorrent. You get the
> > functionality of Git as well. It is truly ingenious.
> >
> > Since I have taken an interest in Smalltalk (I'm still learning) I
> > have salivated at the  possibilities for, say Amber + ipfs.
> >
> > There is currently a call for APIs implemented in other languages;
> > https://github.com/ipfs/ipfs/issues
> > I see no one there is interested in Smalltalk so I though I should
> > undertake it, but it will be many months before I have the knowledge
> > and there is no guarantee that I am up to the task... Now seeing that
> > Masashi is working with filesystems, perhaps you would take an
> > interest in this idea.
> >
> > The inventor Juan Benet has many brilliant ideas and has done several
> > presentations to be found on the ipfs site. Unfortunately, he seems to
> > drink a lot of coffee and talks extremely fast and does not enunciate,
> > making the presentations very difficult to understand for those of
> > whom english is a second language. I can definitely help with this by
> > making a transcript if there is interest.
> >
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
>[hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 23
> ************************************

_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org