New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

publish: support multi-type posts (not planned) #832

Open
snarfed opened this Issue Jul 13, 2018 · 4 comments

Comments

Projects
None yet
1 participant
@snarfed
Owner

snarfed commented Jul 13, 2018

cc @tantek @kartikprabhu. experimental use case: https://indieweb.org/tag-reply#tag_and_comment

the difficulty is, when we convert to AS1 internally, we need to represent it as both a reply and a tag-of, and AS1 doesn't really handle multiple types (or objects) in a single activity: http://activitystrea.ms/specs/json/1.0/#activity , http://activitystrea.ms/specs/json/1.0/#rfc.section.3.4 . that's fine, i can make granary handle multiply valued objectType and verb, it'll just take some work.

in the short term , the more likely answer is that i'll fail fast with a nicer human readable error instead of crashing.

IRC discussion (and earlier). stack trace from the log:

Traceback (most recent call last):
  at json_to_object (/base/data/home/apps/s~brid-gy/8.410945048477799522/local/lib/python2.7/site-packages/granary/microformats2.py:463)
    obj = microformats2.json_to_object(item)
  at attempt_single_item (/base/data/home/apps/s~brid-gy/8.410945048477799522/publish.py:355)
    assert not obj.get('object')
AssertionError

simplified mf2:

{
  "type": ["h-entry"],
  "properties": {
    "tag-of": [{"value": "https://a/post"}],
    "in-reply-to": [{"value": "https://another/post"}],
  }
}

possible AS1 that we could convert it to:

{
  "objectType": ["activity", "comment"],
  "verb": "tag",
  "target": {"url": "https://a/post"},
  "inReplyTo": {"url": "https://another/post"},
}

activity is a qualitatively different object type than comment, so combining them like this is really awkward, and i don't know how to indicate that the tag verb only applies to activity. i expect these and other problems are why AS1 made them singly valued in the first place. :trollface:

@snarfed

This comment has been minimized.

Owner

snarfed commented Jul 13, 2018

...not to mention that i'd have to make granary reasonably handle or error out on multiply valued objectType/verb everywhere. nontrivial. 🙁

@snarfed

This comment has been minimized.

@snarfed snarfed changed the title from github publish: crash on reply post with tag-of to github publish: support combined reply and tag-of posts (low priority) Jul 17, 2018

@snarfed

This comment has been minimized.

Owner

snarfed commented Jul 17, 2018

ok, the crash is now a nice 400 with error message. renamed this issue to cover actually supporting combined reply and tag-of. (low priority, not anytime soon.)

snarfed added a commit to snarfed/granary that referenced this issue Jul 17, 2018

snarfed added a commit to snarfed/granary that referenced this issue Jul 17, 2018

snarfed added a commit that referenced this issue Jul 17, 2018

@snarfed snarfed removed the now label Jul 17, 2018

snarfed added a commit that referenced this issue Nov 25, 2018

publish: document order of precedence for interpreting original post …
…type

basically post type discovery, but with tag replies added.

for #849 #832
@snarfed

This comment has been minimized.

Owner

snarfed commented Nov 25, 2018

I'm generalizing this issue to cover all multi-type posts that Bridgy Publish would have to translate to more than one action inside a silo.

i don't plan to support those, for a few reasons beyond just the AS1 implementation details above. specifically:

  • atomicity. right now, a bridgy publish request either succeeds completely or falls completely. multi-type parts could partially succeed, ie complete one action inside the silo but fail another.
  • recovery. when an attempt partially succeeds, and the user retries, what should we do? we can't always roll back the silo action, nor can we always safely retry just the failed part(s). more on that in #812.
  • UX. it's harder to clearly preview a multi-type post or communicate about it to the user in error messages, etc.
  • partial support. if we can publish one part of a multi-type post but not another, it's unclear what we should do.

this begs the question, what should we do with multi type posts then? we could either return an error, which we currently do with the reply+tag posts described here, or we could pick a single part of them, which we currently do with all other multi-type posts. i documented that in b42365f yesterday.

erroring out is probably safer, and follows the Principle of Least Surprise, but publishing a single part is more convenient and expected by current users. 🤷

@snarfed snarfed changed the title from github publish: support combined reply and tag-of posts (low priority) to publish: support multi-type posts (not planned) Nov 25, 2018

snarfed added a commit that referenced this issue Nov 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment