• Brad Koehn ☑️
    Brad Koehn ☑️
    2016-09-03

    Kudos to @GreyKnight for chatting through some ideas and pointing out some things I'd missed. Good brainstorming.

    0
  • harry haller
    harry haller
    2016-09-03

    all I want is a client - not a server

    0
  • Jason Robinson (old account)
    Jason Robinson (old account)
    2016-09-03

    Cool concept, pity don't see how it could be integrated to things like Diaspora. I guess the client could push content out since its easy for you to host the necessary user public key etc. But that would be just dummy cross posting, not federation.

    0
  • Brad Koehn ☑️
    Brad Koehn ☑️
    2016-09-03

    It's possible to set up a gateway between the two; the SHS data is all discoverable. It hasn't been a design goal, frankly. I have enough on my plate. The gateway would have to impersonate an SHS environment for each Federation user. But the underlying models are similar enough that it would be easy to do. Where's the schema for the federation model?

    0
  • Jason Robinson (old account)
    Jason Robinson (old account)
    2016-09-03

    Yeah I realize that wouldn't be an initial goal. It's just that personally I would see it a huge effort to build something where you might not have more than a few users, unless you strike lucky. But if you tie it into the existing federated networks, users using your software immediately are able to socialize with tens of thousands of other users - even if they run a different software stack. That is the true beauty of federation. This is the decision from the start I took with Socialhome, to ensure all content can federate. At the same time there is nothing specific to say Diaspora, the protocol layer is outside so it can be switched if need be as long as the API is adjusted.

    I'm not sure there are more up to date docs, the old ones [in the wiki]https://wiki.diasporafoundation.org/Federation_protocol_overview) are mostly up to date.

    0
  • greyknight@pod.orkz.net
    greyknight@pod.orkz.net
    2016-09-03

    The big red text at the top of that wiki page doesn't fill me with massive amounts of confidence though. ;-)

    0
  • Brad Koehn ☑️
    Brad Koehn ☑️
    2016-09-04

    The Federation's assumption that everything's always online (and therefore only support server push) is disappointing. A change to the protocol to support pull, or alternative topic-like push mechanisms, would make it much easier to integrate.

    0
  • Brad Koehn ☑️
    Brad Koehn ☑️
    2016-09-04

    Reading the Salmon specification and its efforts to fight comment spam are interesting. One benefit of SHS is that since everyone hosts their own comments, (and conversely no one has to host/mirror anyone else's), comment spam isn't a problem, nor is censorship. Everyone can speak their mind and comment on anything they can see, and others are free to ignore them. There's no reporting anyone, and there's no burden on podmins to respond to anything.

    The downside is that the client has to reach out to every server for everyone they follow to fetch their content. Fortunately that's become really cheap and the messages are tiny.

    0
  • Jason Robinson (old account)
    Jason Robinson (old account)
    2016-09-04

    The always on requirement could be worked around by postbox type servers, an old idea I've had. Since Diaspora protocol doesn't care where the content comes from (it's signed), a sender could fall back to a postbox server where the clients could pull when needed. This would allow in theory client-only implementers with no server at all. That would allow an SHS gateway too.

    0
  • greyknight@pod.orkz.net
    greyknight@pod.orkz.net
    2016-09-04

    Someone could run a postbox server named ihnp4 and then we can come full circle. ;-)

    0