Re: [D*] Hash driven posts

[Jelle Langbroek]

Absolutely! The decentralization of the pods should not limit the
accessibility of (especially) public posts. I know that there are
still issues with the federation of images, but as you said, the posts
(and hashtags) should federate ofcourse.
I'd like to be able to have a closed or open group to join so I can
talk about the the same topic with people. Groups should federate to,
if they were (already) available in D* ;)
The network should be *one* social network with ofcourse the privacy
that's already built into it.

Thanks for the work!

Jelle

On Tue, Jul 3, 2012 at 4:15 AM, Jay Denebeim <dene...@gmail.com> wrote:
> So, I've been on Diaspora for a few days now. I run
> https://diaspora.deepthot.org and I've noticed an issue with hashtags.
> Since diaspora is push only all the propagation to other pods is driven by
> who you know that's interested in the same hashtags as you. Once it gets to
> another pod I think everyone on that pod can see the message. I'm talking
> about public messages here of course.
> Anyway, I'm thinking there should be a way for all the pods that have a user
> interested in a given hash tag to exchange messages with that tag. I think
> I've come up with a way to do it.
> Is the concept clear? And if so is there any interest in it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "diaspora-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/diaspora-dev/-/5yOV6ZyHDrMJ.
> To post to this group, send email to diaspo...@googlegroups.com.
> To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.

[Jay Denebeim]

I've thought of a couple of ways to do this, The method I've been giving the most thought to is really similar to the way I think diaspora works currently.  Namely you push the content to all of the recipients.  The difference would be in who was doing the pushing.  What I'm thinking is that a pod would be elected for a hash tag, then messages with that hash tag would go to that pod and get pushed from there.  You'd probably want to dedup the messages which means you wouldn't encrypt the recipient.

When someone subscribes to a hashtag they would inform the publisher of that hash tag of their interest, Pubsub in other words.  Now that you have something that owns the hashtag you can have history for it as well.  So when you subscribe to a tag you could receive some amount of history for it, the pods could negotiate it, the owner of the receiving pod could decide how much history they were willing to take.

When a pod sees a new hash tag it will look to see if another pod is running that tag, if there isn't one the pod would take that tag, or perhaps there would be an address that pods that wanted more hashtags could pool into.  This publisher would exist as long as there were any people subscribing to the hash, once the last person goes away it would cease to exist.  All dynamic, which I like ;-)

The way the pod that owns the hashtag would be discovered using a bittorrent like DHT there's already libraries available for it.  You'd hash the hashtag and get back the pod that owns it's url.

Do you see where I'm going with this?

The other method I was thinking of is use the usenet floodfill algorithm.  It's well understood and obviously there's plenty of code that already implements it.  Heck we could even use NNTP.  I can go into quite a bit of detail on how usenet works if we decide to go that way.

The nice thing about using usenet for the public messages would be something I'm concerned about.  History.  In 100 years will the google+ messages still exist for scholars?  How about facebook?  Myspace?  Once they're gone they're gone.  With usenet though each message was replicated thousands of times, I have no doubt those posts will exist in 100 years.

Whew...  Thanks for sticking with me if you'd gotten this far.  How did that sound for a plan?

Jay

[Jelle Langbroek]

That sounds great! Using existing networks in D* would be the way to go I believe. We should be careful not to make the system too complicated because everything stands or falls with the user experience. Of course your idea only adds to that :)
I see no objections to this idea, although I'm not really a dev and can't help you with this. I host a pod and can give you some hosting space or even a server with enough bandwidth if you'd need that to test. I hope you'll give your idea a shot!

Best,
Jelle

Op 3 jul. 2012 22:18 schreef "Jay Denebeim" <dene...@gmail.com> het volgende:

--
You received this message because you are subscribed to the Google Groups "diaspora-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/diaspora-dev/-/h5EupHKd0m4J.

[Tom Scott]

I'm definitely against the use of NNTP, and as a podmin you should be too. 

It's more difficult to keep a pod running when it's depending on several processes to all be up in order to be used to its fullest extent. NNTP would require a whole new process to just handle these hash tag requests. That sounds like a little overkill to me. 

My vote goes toward pub/sub. We can implement it with the existing technology, right in the rails app, or we could use something like Faye. 

Alternatively, we could just wait for the chat to be implemented and tack on hash tag pub/sub to that paradigm, since it will most likely use something like pub/sub to implement live chat. 

-T

[Jay Denebeim]

I'm not at all married to NNTP.  Sadly it never made the leap to the web.  That's why we got all this centralization of message systems.  There was a time where backing message boards with the usenet message protocol would have been a good idea, it's well understood (unfortunately not by the people who wrote the first web message systems) and works really well for what it's for.  Simply too, which is a winner imo.  That's why I suggested it.  Oh by the way, you're using it now, that's what drives google groups.

 Anyway, I think I'll be forking the code in a few days and then I'll write a detailed design document on the project page, if there's any interest I'll get working on it.