Integration of diaspora-federation gem

[dimaursu]

I tried to integrate the gem by keeping the existing interface intact. So far, I can say that this is the status:

• HCard
• webfinger
• Slap
• EncriptedSlap
• MagicEnvelope

The last one is not used in the rest of the code, so we can leave the magic envelope as a internal implementation detail in diaspora-federation gem. If you have any ideas on how to move things forward, I'd be glad to hear. Maybe a top-down approach would have been better.

[dnsco]

I like the direction of this code, but perhaps "Adapters" is too generic a namespace, and something like "Federation" or Diaspora::Federation might yield less confusion.

[jaywink]

Awesome stuff @dimaursu - this is very important work

[DeadSuperHero]

This is definitely a step in the right direction.

If you haven't already, I would recommend talking to @Raven24, who maintains the gem. Honestly, moving the gem repo from Raven24/diaspora-federation to diaspora/diaspora-federation might be useful if we want to have people collaborate on it more frequently.

Maybe worth talking about on Loomio?

[Flaburgan]

foundation?

[dimaursu]

I think I was reading something by Isaac Asimov. All the blame goes on this guy.

[goobertron]

It's fantastic that you're working on this, @dimaursu - thanks very much. Good luck with it!

[dimaursu]

@denniscollective I really don't want the namespacing to 'conflict' with the one used by the library. Also, I want to convey somehow that the files are logic-less, that the heavy lifting is done by diaspora-federation

@DeadSuperHero I think @Raven24 is aware of what I'm doing :-) Also, I don't think loomio is such a good place to do this: just add comments on the code, ideas, etc. right here on Github

A lot of methods have to be stripped out, together with their tests, because most of that is tested in diaspora-federation, there's no point in duplicating those kind of tests. I think we should keep the original contract with the files. I actually broke the HCard contract, but only because it was easy to fix the thing up. If before HCard was a Hash, now it's an object.

diaspora/lib/postzord/dispatcher/private.rb

Line 11 in ead86d3

Salmon::EncryptedSlap.create_by_user_and_activity(user, activity)

For example, with EncryptedSlap we should keep create_by_user_and_activity method and make sure it works. All the other stuff - we don't care about it.

[dnsco]

@dimaursu my worry with adapters as a top level namespace is that it's not very unique so likely to conflict with another gem that reaches for namespace. maybe Federation::Adapters? or Diaspora::Federation::Adapters (it's a lot to type, but less likely to conflict).

[dimaursu]

@Raven24 How do you think we should use the Entities? It's not clear to me how they fit in the current situation, yet they are necessary for most of the gem functionality. Maybe define them as modules, and include them into the existing diaspora* models?
@denniscollective Federation::Adapters sounds doable.

[Raven24]

@dimaursu the entity classes from the gem should replace all the xml stuff we have in the models now.
So, you could for instance make a generator "Adapter" that spits out an Entitfy for a given Model or just put a method that does that into every model.

[Raven24]

no need for adding '.rb' at the end

[Raven24]

I think you could make this PR about Webfinger only, then let's test it in the wild while we think about how to best approach converting the other areas to using the gem.

[jaywink]

+1 for tackling smaller bits at a time

[svbergerem]

Did #6151 supersede this PR?

[SuperTux88]

Oh, I didn't know about this PR. But yes, I think this is superseded now.

[denschub]

Uh. Thanks much, @svbergerem. Closing.